dwarf-2 problem on cc1

dwarf-2 problem on cc1

[Robert Lipe]

[ Two disparate groups copied; please drop the other as appropriate. ] 

I can't tell if this is an GCC problem or a GDB problem.   I'm inclined
to think it's EGCS becuase SCO's 'debug' complains about the binary, too.

I'm looking at GCC 2.95 (i686-UnixWare7.1.0-sysv5) with GDB 4.18.  Small
binaries work OK.   Big ones fail and I need help understanding why.

The easiest way to see this fail is in GCC itself after a full three-stage:

(robertl) rjludi:/home3/negcs/gcc
$ gdb ./cc1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-UnixWare7.1.0-sysv5"...

Dwarf Error: bad offset (0x93000200) in compilation unit header (offset 0x2320b5 + 6).

.gdbinit:8: Error in sourced command file:


Now, if I use GDB on GDB to debug cc1 and set breakpoints on this error,
I can see that it's not anything as "obvious" as a sign extension
problem.

(top-gdb) print /x cu_header
$2 = {length = 0x28000000, version = 0x2, abbrev_offset = 0x93000200, 
  addr_size = 0xce}

That's a pretty bogus looking length.




If I feed that same binary to the SCO dwarf-2 debugger, it complains in 
a different way:

$ debug cc1
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unimplemented DWARFII location operator at offset 0x5237: DW_OP_fbreg
Error: Unimplemented DWARFII debugging information entry in section .debug_info
New program cc1 (process p1) created


It's not strictly size related.   I can invoke gdb on cc1plus and it's 
fine.   gdb on several of the gen* programs and it's fine.   but the inability
to debug cc1 worries me.

Any ideas?

RJL

Re: dwarf-2 problem on cc1

[Robert Lipe]

> I can't tell if this is an GCC problem or a GDB problem.   I'm inclined
> to think it's EGCS becuase SCO's 'debug' complains about the binary, too.

GDB now seems to be off the hook here.

> This GDB was configured as "i686-UnixWare7.1.0-sysv5"...
>                                                                               > Dwarf Error: bad offset (0x93000200) in compilation unit header 
> (offset 0x2320b5 + 6).                                                                        
The problem seems to be one of mixing UDK dot-oh's with EGCS ones.
During the bootstrap the native compiler is used to build libiberty.
All of the "offending" objects that I could find were in the libiberty
directory. [ At one point, didn't we change the EGCS bootstrap to
rebuild libiberty? ]

Sure enough, if I blast libiberty and rebuild it with the freshly built
GCC, and relink cc1 with that libiberty this issue goes away.

It looks like someone still building configure's with an old version of
autoconf that doesn't have the fix that rth donated earlier this year.
So the libiberty that's being built has several .o's in it (like 'memset'
and 'memcpy') that shouldn't even be there.

Why aren't we using the fixed autoconf to generate correct configure 
scripts?  I thought Ben got that fix into 2.13 but will check.

The issue about compatibility with the native compilers is, I suppose,
a completely different problem.  (And one of lesser interest than the
general "something is broken" case.)  I now feel much better about the
reliability of the dwarf generation and handling in EGCS and GDB for
2.95.

...now the issue of dwarf-1 or dwarf-2 even making it through a bootstrap
comes to light. :-)

RJL

Re: dwarf-2 problem on cc1

[Robert Lipe]

Ben, how would you and Jeff about using a post 2.13 autoconf for 2.95?

> Sure enough, if I blast libiberty and rebuild it with the freshly built
> GCC, and relink cc1 with that libiberty this issue goes away.

As crazy as all this sounds, this is indeed triggered by an old version
of autoconf.  If I regenerate libiberty/configure and nuke the caches,
cc1 no longer contains the dwarf records that sends it over the edge.
I was really suprised that the third-stage cc1 contained references to
memset and memcpy but apparently there was a use somewhere that just
couldn't be inlined so we get into the weirdness of mixing native and
gcc objects.

According to autoconf/ChangeLog, 2.13 was released on 1/5.  The patch in
question (and it was Joerne, not Richard.  Sorry.) was installed on 1/9.
The patch was actually submitted in October.

I won't hard-sell you on the idea since some other changes I made in
EGCS reduced this from link failure during bootstrap to "merely" making
cc1 hard to debug.

RJL

Re: dwarf-2 problem on cc1

[Jeffrey A Law]

  In message < 19990613001932.A23053@rjlhome.sco.com >you write:
  > Ben, how would you and Jeff about using a post 2.13 autoconf for 2.95?
My only worry is that by not currently being in the tree it isn't being
tested.  Switching the mainline tree to a newer version seems like a reasonable
thing though.  If these older versions of autoconf are causing problems, then
adding a AC_PREREQ to all the configure.in files seems like a good idea too.

  > I was really suprised that the third-stage cc1 contained references to
  > memset and memcpy but apparently there was a use somewhere that just
  > couldn't be inlined so we get into the weirdness of mixing native and
  > gcc objects.
Not a total suprise.  Sometimes gcc will determine that the system provided
mem* str* functions are better than inlining.  For example unaligned with
a large (or unknown) size will often kick to the library version instead of
inlining.

What I do not get is why an autoconf bug is causing a dwarf2 code generation
problem.  That seems awful weird.
jeff

Re: dwarf-2 problem on cc1

[Robert Lipe]

>   > Ben, how would you and Jeff about using a post 2.13 autoconf for
>   > 2.95?
>
> My only worry is that by not currently being in the tree it isn't
> being tested.  

OK.  I can devise a workaround for the release branch.  I'm not fond of
doc-only workarounds since they invariably don't get read...  I'll try
to come up with something programmatic.

>  Switching the mainline tree to a newer version seems like a
> reasonable thing though.  If these older versions of autoconf are
> causing problems, then adding a AC_PREREQ to all the configure.in
> files seems like a good idea too.

Ben, can I have your guidance on a suitable value for AC_PREREQ for the
EGCS development branch?   2.14?  2.14.1?


> What I do not get is why an autoconf bug is causing a dwarf2 code
> generation problem.  That seems awful weird. jeff

Believe me, it _is_ weird.

The catch is that libiberty is built with the native compiler with -g.
GDB (and indeed, even readelf) go nuts when they see a single object 
linked with both EGCS dwarf2 and natve cc dwarf2 in the same executable.
Yes, I realize that's a different problem that should be addressed.  GDB
handles executables by either tool fine.  Only when mixing them does it 
freak out.

Since we shouldn't be picking up memset and memcpy at all from libiberty
on this host, (and thereby eliminating the mixture of objects) that
seemed like a reasonable starting place.

RJL

Re: dwarf-2 problem on cc1

[Ben Elliston]

> Ben, can I have your guidance on a suitable value for AC_PREREQ for the
> EGCS development branch?   2.14?  2.14.1?

If you want "post 2.13", then "2.13.1" will be sufficient.  We had a
hiccup when I poorly chose 2.14 prior to the 2.14 release.  Now we have
people out there who think they _have_ 2.14.  The next version will
actually be 2.15. ;-(

Ben

Re: dwarf-2 problem on cc1

[Jeffrey A Law]

  In message < Pine.LNX.3.95.990614224534.29401A-100000@moshpit.cygnus.com >you w
rite:
  > > Ben, can I have your guidance on a suitable value for AC_PREREQ for the
  > > EGCS development branch?   2.14?  2.14.1?
  > 
  > If you want "post 2.13", then "2.13.1" will be sufficient.  We had a
  > hiccup when I poorly chose 2.14 prior to the 2.14 release.  Now we have
  > people out there who think they _have_ 2.14.  The next version will
  > actually be 2.15. ;-(
Typical of folks that want to be on the bleeding edge.

What we've started doing is adding a descriptive tag to the version #.

So, for example the mainline egcs source will identify themselves as

gcc-2.96 19990613 (experimental)

If we end up making a gcc-2.96 release it will look something like

gcc-2.96 <date> (release)

jeff

dwarf-2 problem on cc1

[Robert Lipe]

[ Two disparate groups copied; please drop the other as appropriate. ] 

I can't tell if this is an GCC problem or a GDB problem.   I'm inclined
to think it's EGCS becuase SCO's 'debug' complains about the binary, too.

I'm looking at GCC 2.95 (i686-UnixWare7.1.0-sysv5) with GDB 4.18.  Small
binaries work OK.   Big ones fail and I need help understanding why.

The easiest way to see this fail is in GCC itself after a full three-stage:

(robertl) rjludi:/home3/negcs/gcc
$ gdb ./cc1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-UnixWare7.1.0-sysv5"...

Dwarf Error: bad offset (0x93000200) in compilation unit header (offset 0x2320b5 + 6).

.gdbinit:8: Error in sourced command file:


Now, if I use GDB on GDB to debug cc1 and set breakpoints on this error,
I can see that it's not anything as "obvious" as a sign extension
problem.

(top-gdb) print /x cu_header
$2 = {length = 0x28000000, version = 0x2, abbrev_offset = 0x93000200, 
  addr_size = 0xce}

That's a pretty bogus looking length.




If I feed that same binary to the SCO dwarf-2 debugger, it complains in 
a different way:

$ debug cc1
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unrecognized debugging information at offset 0x2320b5
Error: Inconsistent state in function Dwarf2build::get_syminfo at line 788
Error: Unimplemented DWARFII location operator at offset 0x5237: DW_OP_fbreg
Error: Unimplemented DWARFII debugging information entry in section .debug_info
New program cc1 (process p1) created


It's not strictly size related.   I can invoke gdb on cc1plus and it's 
fine.   gdb on several of the gen* programs and it's fine.   but the inability
to debug cc1 worries me.

Any ideas?

RJL

Re: dwarf-2 problem on cc1

[Jeffrey A Law]

  In message < 19990613001932.A23053@rjlhome.sco.com >you write:
  > Ben, how would you and Jeff about using a post 2.13 autoconf for 2.95?
My only worry is that by not currently being in the tree it isn't being
tested.  Switching the mainline tree to a newer version seems like a reasonable
thing though.  If these older versions of autoconf are causing problems, then
adding a AC_PREREQ to all the configure.in files seems like a good idea too.

  > I was really suprised that the third-stage cc1 contained references to
  > memset and memcpy but apparently there was a use somewhere that just
  > couldn't be inlined so we get into the weirdness of mixing native and
  > gcc objects.
Not a total suprise.  Sometimes gcc will determine that the system provided
mem* str* functions are better than inlining.  For example unaligned with
a large (or unknown) size will often kick to the library version instead of
inlining.

What I do not get is why an autoconf bug is causing a dwarf2 code generation
problem.  That seems awful weird.
jeff

Re: dwarf-2 problem on cc1

[Ben Elliston]

> Ben, can I have your guidance on a suitable value for AC_PREREQ for the
> EGCS development branch?   2.14?  2.14.1?

If you want "post 2.13", then "2.13.1" will be sufficient.  We had a
hiccup when I poorly chose 2.14 prior to the 2.14 release.  Now we have
people out there who think they _have_ 2.14.  The next version will
actually be 2.15. ;-(

Ben

Re: dwarf-2 problem on cc1

[Robert Lipe]

Ben, how would you and Jeff about using a post 2.13 autoconf for 2.95?

> Sure enough, if I blast libiberty and rebuild it with the freshly built
> GCC, and relink cc1 with that libiberty this issue goes away.

As crazy as all this sounds, this is indeed triggered by an old version
of autoconf.  If I regenerate libiberty/configure and nuke the caches,
cc1 no longer contains the dwarf records that sends it over the edge.
I was really suprised that the third-stage cc1 contained references to
memset and memcpy but apparently there was a use somewhere that just
couldn't be inlined so we get into the weirdness of mixing native and
gcc objects.

According to autoconf/ChangeLog, 2.13 was released on 1/5.  The patch in
question (and it was Joerne, not Richard.  Sorry.) was installed on 1/9.
The patch was actually submitted in October.

I won't hard-sell you on the idea since some other changes I made in
EGCS reduced this from link failure during bootstrap to "merely" making
cc1 hard to debug.

RJL

Re: dwarf-2 problem on cc1

[Robert Lipe]

> I can't tell if this is an GCC problem or a GDB problem.   I'm inclined
> to think it's EGCS becuase SCO's 'debug' complains about the binary, too.

GDB now seems to be off the hook here.

> This GDB was configured as "i686-UnixWare7.1.0-sysv5"...
>                                                                               > Dwarf Error: bad offset (0x93000200) in compilation unit header 
> (offset 0x2320b5 + 6).                                                                        
The problem seems to be one of mixing UDK dot-oh's with EGCS ones.
During the bootstrap the native compiler is used to build libiberty.
All of the "offending" objects that I could find were in the libiberty
directory. [ At one point, didn't we change the EGCS bootstrap to
rebuild libiberty? ]

Sure enough, if I blast libiberty and rebuild it with the freshly built
GCC, and relink cc1 with that libiberty this issue goes away.

It looks like someone still building configure's with an old version of
autoconf that doesn't have the fix that rth donated earlier this year.
So the libiberty that's being built has several .o's in it (like 'memset'
and 'memcpy') that shouldn't even be there.

Why aren't we using the fixed autoconf to generate correct configure 
scripts?  I thought Ben got that fix into 2.13 but will check.

The issue about compatibility with the native compilers is, I suppose,
a completely different problem.  (And one of lesser interest than the
general "something is broken" case.)  I now feel much better about the
reliability of the dwarf generation and handling in EGCS and GDB for
2.95.

...now the issue of dwarf-1 or dwarf-2 even making it through a bootstrap
comes to light. :-)

RJL

Re: dwarf-2 problem on cc1

[Jeffrey A Law]

  In message < Pine.LNX.3.95.990614224534.29401A-100000@moshpit.cygnus.com >you w
rite:
  > > Ben, can I have your guidance on a suitable value for AC_PREREQ for the
  > > EGCS development branch?   2.14?  2.14.1?
  > 
  > If you want "post 2.13", then "2.13.1" will be sufficient.  We had a
  > hiccup when I poorly chose 2.14 prior to the 2.14 release.  Now we have
  > people out there who think they _have_ 2.14.  The next version will
  > actually be 2.15. ;-(
Typical of folks that want to be on the bleeding edge.

What we've started doing is adding a descriptive tag to the version #.

So, for example the mainline egcs source will identify themselves as

gcc-2.96 19990613 (experimental)

If we end up making a gcc-2.96 release it will look something like

gcc-2.96 <date> (release)

jeff

Re: dwarf-2 problem on cc1

[Robert Lipe]

>   > Ben, how would you and Jeff about using a post 2.13 autoconf for
>   > 2.95?
>
> My only worry is that by not currently being in the tree it isn't
> being tested.  

OK.  I can devise a workaround for the release branch.  I'm not fond of
doc-only workarounds since they invariably don't get read...  I'll try
to come up with something programmatic.

>  Switching the mainline tree to a newer version seems like a
> reasonable thing though.  If these older versions of autoconf are
> causing problems, then adding a AC_PREREQ to all the configure.in
> files seems like a good idea too.

Ben, can I have your guidance on a suitable value for AC_PREREQ for the
EGCS development branch?   2.14?  2.14.1?


> What I do not get is why an autoconf bug is causing a dwarf2 code
> generation problem.  That seems awful weird. jeff

Believe me, it _is_ weird.

The catch is that libiberty is built with the native compiler with -g.
GDB (and indeed, even readelf) go nuts when they see a single object 
linked with both EGCS dwarf2 and natve cc dwarf2 in the same executable.
Yes, I realize that's a different problem that should be addressed.  GDB
handles executables by either tool fine.  Only when mixing them does it 
freak out.

Since we shouldn't be picking up memset and memcpy at all from libiberty
on this host, (and thereby eliminating the mixture of objects) that
seemed like a reasonable starting place.

RJL