From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30726 invoked by alias); 29 Mar 2013 20:04:54 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 30711 invoked by uid 48); 29 Mar 2013 20:04:46 -0000 From: "dick.guertin at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions Date: Fri, 29 Mar 2013 20:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dick.guertin at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-SW-Source: 2013-03/txt/msg02216.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #4 from Dick Guertin 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".