[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions

["dick.guertin at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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".