Re: stabs difference gcc 2.95.3 -> 3.4.3

[Daniel Jacobowitz <drow@false.org>]

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