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.
Are you sure that this is not a bug in Apple's part of the toolchain and not g++?
(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.
(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?
(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".
(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.
(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.
Is there a replacement for Apple's linker that would run on Snow Leopard?
(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.
(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.