stabs difference gcc 2.95.3 -> 3.4.3

stabs difference gcc 2.95.3 -> 3.4.3

[Fabian Cenedese]

Hi

The following is about a cross-compiled tool chain, both gcc and gdb are
running on cygwin but the target is a PPC embedded board. I don't know
if the problem lies with gcc or gdb.

We have an older tool chain with gcc 2.95.3. We compile our cpp files
in two steps, basically
1. gcc -S file.cpp -o file.s
2. gcc file.s -o file.o

We do this as we need both the assembler file and binary. These binaries
get then linked together with ld and a linker script. This works fine.

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
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 "Action__17_TASK_CLASS_NAME_" is a function at address 0x153c.
(gdb) info line '_TASK_CLASS_NAME_::Action(void)'
Line 128 of "N:\Indel-PPC\Tests\gcc3\applicat\src\CTaskTemplateClass.cpp"
   starts at address 0x153c <Action__17_TASK_CLASS_NAME_> and ends at 0x155c <Action__17_TASK_CLASS_NAME_+32>.

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?
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.

Now: Is this a gdb or a gcc problem? Is there some switch or something
that may help me further or is the stabs support in gcc regressing as
mentioned in this post by Michael Chastain:

http://gcc.gnu.org/ml/gcc/2004-07/msg00479.html

Is there sense in posting this to the gcc list?

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]

As we would like to stay on stabs I didn't pursue this further but it wasn't
very promising.

Thanks for reading this lengthy mail.

bye  Fabi

Re: stabs difference gcc 2.95.3 -> 3.4.3

[Daniel Jacobowitz]

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

Re: stabs difference gcc 2.95.3 -> 3.4.3

[Fabian Cenedese]

>> 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.

That was just lying around from my last experiments. As it worked fine
with output of the older gcc I had no reason (yet) to upgrade.

>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.

Well, as the currently used compiler 2.95.3 is even older and I supposed
that the stabs format should be compatible I didn't especially try the
newest versions but I may now.

>> 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.

I thought so. When I do it in one step it works better, still not perfect though.

>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.

The -g is given to gcc, I don't know if that gets passed on to as. But so 
was the setup with the older compiler as well, where it worked.

>> 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.

Hehe... I almost expected this answer, that's the same we tell our
customers when they don't have our newest tools. I'll see what
I can do.

Thanks for answering.

bye  Fabi

Re: stabs difference gcc 2.95.3 -> 3.4.3

[Daniel Jacobowitz]

On Thu, Mar 30, 2006 at 04:33:11PM +0200, Fabian Cenedese wrote:
> Well, as the currently used compiler 2.95.3 is even older and I supposed
> that the stabs format should be compatible I didn't especially try the
> newest versions but I may now.

The C++ front end has gotten much more sophisticated.  Namespace
debugging works in DWARF-2, but fails badly in stabs.

> The -g is given to gcc, I don't know if that gets passed on to as. But so 
> was the setup with the older compiler as well, where it worked.

GCC 2.95.x predates assembler -g support; GCC 3.4.x doesn't.

-- 
Daniel Jacobowitz
CodeSourcery

Re: stabs difference gcc 2.95.3 -> 3.4.3

[Fabian Cenedese]

At 10:20 30.03.2006 -0500, Daniel Jacobowitz wrote:
>On Thu, Mar 30, 2006 at 04:33:11PM +0200, Fabian Cenedese wrote:
>> Well, as the currently used compiler 2.95.3 is even older and I supposed
>> that the stabs format should be compatible I didn't especially try the
>> newest versions but I may now.
>
>The C++ front end has gotten much more sophisticated.  Namespace
>debugging works in DWARF-2, but fails badly in stabs.
>
>> The -g is given to gcc, I don't know if that gets passed on to as. But so 
>> was the setup with the older compiler as well, where it worked.
>
>GCC 2.95.x predates assembler -g support; GCC 3.4.x doesn't.

Can I somehow prevent gcc from relaying it to as? Something like
-Wa,(no, don't do -g)? I didn't find a matching parameter on

http://sourceware.org/binutils/docs-2.16/as/Invoking.html#Invoking

But then again it isn't mentioned either that as would take -g.

bye  Fabi

Re: stabs difference gcc 2.95.3 -> 3.4.3

[Daniel Jacobowitz]

On Fri, Mar 31, 2006 at 03:54:28PM +0200, Fabian Cenedese wrote:
> At 10:20 30.03.2006 -0500, Daniel Jacobowitz wrote:
> >On Thu, Mar 30, 2006 at 04:33:11PM +0200, Fabian Cenedese wrote:
> >> Well, as the currently used compiler 2.95.3 is even older and I supposed
> >> that the stabs format should be compatible I didn't especially try the
> >> newest versions but I may now.
> >
> >The C++ front end has gotten much more sophisticated.  Namespace
> >debugging works in DWARF-2, but fails badly in stabs.
> >
> >> The -g is given to gcc, I don't know if that gets passed on to as. But so 
> >> was the setup with the older compiler as well, where it worked.
> >
> >GCC 2.95.x predates assembler -g support; GCC 3.4.x doesn't.
> 
> Can I somehow prevent gcc from relaying it to as? Something like
> -Wa,(no, don't do -g)? I didn't find a matching parameter on
> 
> http://sourceware.org/binutils/docs-2.16/as/Invoking.html#Invoking

You're compiling in two steps already; how about not passing -g the
second time?

> But then again it isn't mentioned either that as would take -g.

It's translated to --gdwarf-2 or --gstabs.

-- 
Daniel Jacobowitz
CodeSourcery

Re: stabs difference gcc 2.95.3 -> 3.4.3

[Fabian Cenedese]

>> Can I somehow prevent gcc from relaying it to as? Something like
>> -Wa,(no, don't do -g)? I didn't find a matching parameter on
>> 
>> http://sourceware.org/binutils/docs-2.16/as/Invoking.html#Invoking
>
>You're compiling in two steps already; how about not passing -g the
>second time?

Yeah, I came to that conclusion as well, or even better calling as directly.

>> But then again it isn't mentioned either that as would take -g.
>
>It's translated to --gdwarf-2 or --gstabs.

Thanks for your help, I'll shut up now :)

bye  Fabi