From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1271 invoked by alias); 30 Mar 2006 14:00:29 -0000 Received: (qmail 1261 invoked by uid 22791); 30 Mar 2006 14:00:28 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 30 Mar 2006 14:00:27 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FOxhH-0007hc-Rr; Thu, 30 Mar 2006 09:00:23 -0500 Date: Thu, 30 Mar 2006 15:20:00 -0000 From: Daniel Jacobowitz To: Fabian Cenedese Cc: gdb@sourceware.org Subject: Re: stabs difference gcc 2.95.3 -> 3.4.3 Message-ID: <20060330140023.GA29500@nevyn.them.org> Mail-Followup-To: Fabian Cenedese , gdb@sourceware.org References: <5.2.0.9.1.20060330083638.01f6da00@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.1.20060330083638.01f6da00@NT_SERVER> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00221.txt.bz2 On Thu, Mar 30, 2006 at 09:12:26AM +0200, Fabian Cenedese wrote: > This is the working file of gcc 2.95.3, looking up _TASK_CLASS_NAME_::Action: > GNU gdb 6.2.50_2004-10-14-cvs First of all, this is an older GDB. You might want to try a current one. Secondly, since you're trying to debug C++ with stabs, the basic reaction is that you'll get what you deserve - the stabs produced by GCC are missing a lot of information that's available in the default DWARF-2 format. > We now wanted to upgrade and tried the same with gcc 3.4.3. To stay > as much compatible to our other tools as possible we use -gstabs+ even > if this is not the default format. However this gives some different results. > > Now doing the same with the result of gcc 3.4.3: > GNU gdb 6.2.50_2004-10-14-cvs > Copyright 2004 Free Software Foundation, Inc. > This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi"... > (gdb) info address _TASK_CLASS_NAME_::Action > Symbol "_TASK_CLASS_NAME_::Action" is at 0x1650 in a file compiled without debugging. > (gdb) info line '_TASK_CLASS_NAME_::Action()' > Line 128 of "N:\Indel-PPC\Tests\gcc3\bin343\CTaskTemplateClass.s" > starts at address 0x1650 <_ZN17_TASK_CLASS_NAME_6ActionEv> and ends at 0x1668 <_ZN17_TASK_CLASS_NAME_6ActionEv+24>. > > First thing: why does gdb say that the function is in a file compiled without > debugging when it still knows where to find it? We'd need a testcase, sorry. But this is likely to be related to... > Second thing: why is the assembler file given as source file? Of course it > _is_ the source file given our two steps compiling. But the same was true > with the old tool chain where it worked fine. Also, in the generated assembler > file is the first line a directive: > .file "CTaskTemplateClass.cpp" > so it should be clear where this code comes from. ... this. Probably gas has been passed the -g option, and generated its own debug information, which caused GDB to see debug info for the assembly file instead of for the source file. You might want to check that. > Is there sense in posting this to the gcc list? Unlikely, since you're using such old compilers. > Just for checking if this would work better I also tried -gdwarf-2. Got even worse: > GNU gdb 6.2.50_2004-10-14-cvs > This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi"...Dwarf Error: Could not find abbrev number 128 > [in module /cygdrive/n/IMD/Bin/Gnu32_new/gcc3.x] Either this is a linker bug, or a GDB bug. In either case, it is almost certainly fixed in current versions of either. The current releases are GCC 4.1.0, binutils 2.16.1, and GDB 6.4. -- Daniel Jacobowitz CodeSourcery