http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783
--- Comment #4 from Dick Guertin <dick.guertin at gmail dot com> 2013-03-29 20:04:45 UTC --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Are you sure that this is not a bug in Apple's part of the toolchain and > > > not > > > g++? > > > > I'm almost positive. But you need to define the term "toolchain" since that > > doesn't make sense to me. > > http://en.wikipedia.org/wiki/Toolchain > > > I know if I compile withthe -g option using the g++ > > version 4.0.1 on Tiger, and link the executable module, it can be debugged > > with > > gdb on both Tiger AND Snow Leopard. But if I compile with g++ version 4.2 > > or > > Is 4.2 a typo or are you really saying this applies to old versions and not > just 4.7? > > > above on Snow Leopard, the linked module can NOT be debugged. I've used the > > "maint" command with gdb to get the symbol-tables output on both Tiger and > > Snow > > Leopard, the the object decks don't contain the same information. > > > > Sorry to say, my research shows that the "g++" compiler on Snow Leopard no > > longer places symbols in the linked module that have any meaning to "gdb". > > The > > only symbols found are the made-up symbols created to make ALL symbols > > unique. > > Here is a brief sample: > > > > `_Z5DoSVCi', function, 0x151dd > > `_Z7SEBTrapv', function, 0x1383c > > > > Those same symbols in Tiger were like this: > > > > `_Z5DoSVCi' `DoSVC(int)', FUNCTION, 0x1394c > > `_Z7SEBTrapv' `SEBTrap()', FUNCTION, 0xf994 > > > > The "signature" is what "gdb" needs to resolve things like: break > > emsvc.c:DoSVC > > Furthermore, you must still have all the "object decks", like emsvc.o, > > because > > Snow Leopard's "g++" apparently does not carry the symbols in the linked > > module > > anymore. > > If the symbols are in emsvc.o then the problem is probably not with g++, > because after it creates a .o file GCC doesn't do anything else, it just > invokes the linker, which is Apple's part of the toolchain. > > Also, what is your gdb version? Johanathan, 4.2 was NOT a typo. That was the version of g++ that came with Snow Leopard. It was failing. I replaced it by version 4.7 obtained from SourceForge, and it fails in EXACTLY the same way. As for the symbols, only the artificially created symbols are in the object decks, like _Z5DoSVCi, but the "signatures" are in the linked module (emg) because that's where gdb gets them on Tiger (g++ 4.0.1). Tiger doesn't need the object decks to debug a linked module. With g++ 4.2 OR 4.7, the linked module does NOT have the signatures, and gdb tries to obtain them from the object decks, therefore you must RETAIN the ojbect decks. But that doesn't help because gdb can't constuct the signatures. So debugging fails in the sense that you can't reference user-known symbols. The artificial symbols are not known to the user unless they've created a text file with the "maint" command using gdb. That's why I know the signatures are NOT in the linked module, because gdb reads the linked module to create the text file. Therefore, the linker must be adding the "signatures" to the linked module, probably by reading the object decks AND the source files. But that only seems to be happening with g++ 4.0.1 and associated linker. The linker with versions 4.2 and higher must have revised linkers that DO NOT create the "signatures".
