Re: dwarf-2 problem on cc1

[Robert Lipe <robertl@sco.com>]

> 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