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

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

[dick.guertin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783

             Bug #: 56783
           Summary: g++ does not supply signatures for gdb on g++ 4.7
                    versions
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dick.guertin@gmail.com


Steps to reproduce:

On Snow Leopard, compile c-programs with -g option using g++ to create a linked
module for execution.  Use gdb to read the module, and attempt to set
breakpoints.  No symbols are found.  g++ no longer places the "signatures" in
the linked module, or the object decks, so gdb can't find the signatures to
satisfy something like:  break emsvc.c:DoSVC ;  However, the same source
compiled with g++ and linked on Tiger, when copied to Snow Leopard, can set
breakpoints.


Actual results:

dickguertin$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-apple-darwin11.4.0/4.7.1/lto-wrapper
Target: x86_64-apple-darwin11.4.0
Configured with: ../gcc-4.7.1/configure --enable-languages=fortran
Thread model: posix
gcc version 4.7.1 (GCC) 

dickguertin$ gdb -q emg 2>/dev/null
Reading symbols for shared libraries ..... done
(gdb) maint print psymbols emg.sym
(gdb) break emsvc.c:DoSVC
Function "DoSVC" not defined in file emsvc.c.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) quit
dickguertin$ 


Expected results:

In the command sequence shown above, the breakpoint should have been set.  The
"maint" command creates a symbol-table text-file (emg.sym), which shows that
the signatures are no longer included in either the object decks or linked
module (emg).  Similar commands on Tiger produce symbol-tables with signatures,
and breakpoints can be found (and set) by gdb on Tiger, and even the gdb on
Snow Leopard.

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

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |debug

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-03-29 17:21:30 UTC ---
Are you sure that this is not a bug in Apple's part of the toolchain and not
g++?

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

[dick.guertin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783

--- Comment #2 from Dick Guertin <dick.guertin at gmail dot com> 2013-03-29 17:57:43 UTC ---
(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.  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
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.

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

[redi at gcc dot gnu.org]

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?

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

[dick.guertin at gmail dot com]

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

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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-03-29 20:56:29 UTC ---
(In reply to comment #4)
> 
> 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.

Then the problem is unlikely to be GCC.  I'm fairly sure Apple's modified GCC
4.2 should work with their own OS and linker.  Maybe the problem is with your
GDB version, which you haven't stated.

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

GCC doesn't have an associated linker, it is using the Apple linker that comes
with the OS.

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

[dick.guertin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783

--- Comment #6 from Dick Guertin <dick.guertin at gmail dot com> 2013-03-29 21:19:47 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > 
> > 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.
> 
> Then the problem is unlikely to be GCC.  I'm fairly sure Apple's modified GCC
> 4.2 should work with their own OS and linker.  Maybe the problem is with your
> GDB version, which you haven't stated.
> 
> > 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".
> 
> GCC doesn't have an associated linker, it is using the Apple linker that comes
> with the OS.

First, my apology for not giving the gdp version.  I assume you meant this:
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)

Next, let me point out that this gdb works correctly with source modules
compiled and linked on Tiger with g++ 4.0.1 and Mac OS X 10.4.11.  It also
worked on Leopard, system 10.5.  But it now fails with the same sources
compiled and link with g++ 4.2 or higher on Mac OS X 10.6.  Therefore, it must
be the Apple linker because if I use "vi" to view a linked module, I find path
information to sources in the OS 10.4 system, but paths to objects in the 10.6
system.  If gdb reads the 10.4 linked module, it then reads the sources and
constructs the symbol-table with signatures.  But if gdb reads the 10.6 linked
modules, all it finds are references to the objects, which do NOT carry the
signature information.

So, I'm forced to agree with you,  Unfortunately, Apple says they won't "fix"
it in Snow Leopard (10.6), which is where the linker resides.  Bummer.

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

[dick.guertin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783

--- Comment #7 from Dick Guertin <dick.guertin at gmail dot com> 2013-03-29 21:22:54 UTC ---
Is there a replacement for Apple's linker that would run on Snow Leopard?

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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-03-30 12:10:41 UTC ---
(In reply to comment #6)
> First, my apology for not giving the gdp version.  I assume you meant this:
> GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)

Donate it to a museum and try a GDB version that was released this side of the
last ice age.  GCC 4.5 and later require at least GDB 7.0:
http://gcc.gnu.org/gcc-4.5/changes.html

This is not  GCC bug.

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

[dick.guertin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783

--- Comment #9 from Dick Guertin <dick.guertin at gmail dot com> 2013-03-30 14:52:33 UTC ---
(In reply to comment #8)
> (In reply to comment #6)
> > First, my apology for not giving the gdp version.  I assume you meant this:
> > GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
> 
> Donate it to a museum and try a GDB version that was released this side of the
> last ice age.  GCC 4.5 and later require at least GDB 7.0:
> http://gcc.gnu.org/gcc-4.5/changes.html
> 
> This is not  GCC bug.

Johnathan, this may not be a GCC bug, but it isn't a GDB bug either.  I went
back to g++ 4.2 that came with the Xcode, which is where I started.  Of course,
the problem persists.  The "problem" is in the linked modules.  They don't
contain the paths back to the "source" modules.  "g++" compiles source into
objects; "ld" links objects into a link module, but knows about the sources. 
In Mac OS X 10.4.11, the linker places path-references back to sources.  In
10.5 and 10.6, it references back to objects.  When "gdb" reads the linked
module, it needs the sources to construct the "signatures" for the
symbol-table.  Paths to objects are worthless in this regard.  The fact that
"gdb" works properly with linked modules brought across from OS 10.4.11 (with
identical sources on identical paths), shows that the path-references to
sources is the key.  The latest "ld" is failing.

Of course, another problem would be the lack of sources when trying to "gdb"
the linked module.  I achieved that simply by renaming one of the directories
leading to the sources, and even my 10.4.11 linked module then failed to debug.