[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
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.
[Bug c++/56783] New: g++ does not supply signatures for gdb on g++ 4.7 versions
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: unassig...@gcc.gnu.org ReportedBy: dick.guer...@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
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
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
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
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?
