http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-03-29 19:27:03 UTC --- (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?
