View Full Version : demangling c++ symbols

03-17-2008, 01:38 AM
Is it possible to optionally demangle C++ symbols in totalview?


04-01-2008, 02:02 PM
Hello Reiner,

Do you mean can we NOT demangle them by choice? Or do you have some C++ symbols that are mangled and are not getting demangled? We do try to demangle all C++ symbols that we can. Sometimes, due to a particular compiler, or a compiler on a platform we don't expect, we don't quite get it right, and the symbol is not demangled. You can actually choose your demangler, if you find the default choice is not working right. In the CLI (tools->command line) you can do a

dset TV*demangle*

to find out what the current demangler is. Check the Reference Guide in our Doc set for possible choices. You'll find references under TV::Namespace under the TotalVIew Debugger Variables, or in Command-Line Options under the Debugger Syntax section.


04-02-2008, 12:39 AM
I'm working on solaris/sparc and don't see any demangled symbols there.
I assumed, that there is a switch, I have to turn on. The default demangler is set to spro
there. I changed it to spro5, because our executable is build with Sun Studio 11, but nothing changed.
Did I do anything wrong?


d4.<> dwhere
> 0 __lwp_park PC=0xffffffff7da182b8, FP=0xffffffff7fffdc30 [/lib/sparcv9/libthread.so.1]
1 cond_wait_queue PC=0xffffffff7da1550c, FP=0xffffffff7fffdc30 [/lib/sparcv9/libthread.so.1]
2 _cond_wait_cancel PC=0xffffffff7da15cbc, FP=0xffffffff7fffdce0 [/lib/sparcv9/libthread.so.1]
3 _pthread_cond_wait PC=0xffffffff7da15cf8, FP=0xffffffff7fffdd90 [/lib/sparcv9/libthread.so.1]
4 __1cbFRTESync_CountingSystemSemaphoreEWait6ML_b_ PC=0x10113ea0c, FP=0xffffffff7fffe650 [/sapdb/LCB/db/pgm/kernel]
5 __1cVRTEKernel_TerminationSWaitForTermination6M_v_ PC=0x1010ef69c, FP=0xffffffff7fffe7d0 [/sapdb/LCB/db/pgm/kernel]
6 __1cRRTEKernel_StartupKThreadMain6M_i_ PC=0x1010e9040, FP=0xffffffff7ffff090 [/sapdb/LCB/db/pgm/kernel]
7 __1cQRTEThread_ThreadLCThreadMain6Fpv_1_ PC=0x101044df8, FP=0xffffffff7ffff170 [/sapdb/LCB/db/pgm/kernel]
8 __1cQRTEThread_ThreadbFAppointMainThreadToThreadOb ject6MirnUSAPDBErr_MessageList__n0AHThrdRet__ PC=0x101044768, FP=0xffffffff7ffff390 [/sapdb/LCB/db/pgm/kernel]
9 __1cRRTEKernel_StartupEMain6M_i_ PC=0x1010e754c, FP=0xffffffff7ffffa80 [/sapdb/LCB/db/pgm/kernel]
d4.<> dset TV*demangle*
TV::current_cplus_demangler spro5
TV::current_fortran_demangler sunpro_f9x_4
TV::force_default_cplus_demangler false
TV::force_default_f9x_demangler false

04-02-2008, 01:13 AM
I have to add, that I'm debugging an optimized build (compiled without -g).
How does Totalview identify symbols as C++ symbols?
Is there a global language parameter I have to set?

Regards, Reiner

04-02-2008, 01:11 PM
Hello Reiner,

I would suspect that we see no debug information and then decide there is not enough information to bother trying to demangle the symbols. All this information would be captured in the debug info when you compile with -g. Of course, if this is legacy code, you may not have the option of recompiling it. Since the context can shift quickly between stack frames, we really rely on the debug info to tell us what the language is, rather than having a global language setting.

Does that make sense?


04-03-2008, 02:36 AM
Hi Peter,

I agree, that it makes sense to get language information from the debug information (e.g. from the extension of the filename),
if available. Unfortunately, I often have to debug optimized builds, because I usually debug on unix only,
when platform specific problems occur. In most cases, this kind of problems only show up, when turning optimization on.
I also use assembly level debugging in this case, because matching optimized code with source code is
inaccurate in most cases ( so I don't use -g and -O together at all ). I just use the build, that is being delivered to customers ..

I do the matching of assembly to source on my own, so I can see, what exactly happens "behind the scenes".
This would be easier, if a global language switch would be available, that turns demangling on, even if no debug information is available
.. otherwise, if have to demangle manually, if necessary ..


04-03-2008, 09:26 AM
Hello Reiner,

I understand your position. I'm glad you understand the pitfalls of debugging optimized code. Not everyone gets it ;-) In this case, since you do understand what is going on, you might want to turn on -g anyway, with -O, and this will give you the demangling. You can still debug the assembler (code movement does make source level debugging almost useless) by going to View->Source As -> Assembler. You can step through this with the keyboard shortcuts 'x' and 'i' for next and step by instruction.

My rule of thumb when debugging optimized code is to look for uninitialized variables. Compiling with -g will often cause these to be zero'd out, and your application runs fine. But the compiler writers figure you know what you're doing if you optimize the code, so those same variables will pick up random memory values, and all bets are off. Of course, other things can and do go wrong, but uninitialized variables count for a large number of optimized code problems. Finding them can be a chore itself depending on the size of the code.

If you like, we can enter an enhancement request for setting a global language so the demangling will take place in cases like this. I'd just request you send a message to support@totalviewtech.com so we can log this officially. I don't always get to the forums on a regular basis. Requests to the support center are more formally tracked.