RE: [libunwind] libunwind segv with gcc 2.96 programs run on RedhatEL 3 with GLIBC 2.3.2

[Jim Wilson]

On Wed, 2004-02-11 at 08:34, Harrow, Jerry wrote:
> If gdb is patched to use libunwind, does that mean you cannot debug
> applications built with Gcc 2.96.  Perhaps GDB can recover a bit better
> because it is running outside the process, but it sounds like it may not
> work at all.

The unwind info is only used for stack backtraces, as far as I know.  So
that is the only gdb feature that can be affected.  The rest of the
debugger will work as well as it ever did.

Gdb without libunwind does stack backtraces very poorly for IA-64,
especially when code is optimized, in which case the backtraces tend to
be useless.  With libunwind, I would expect them to be better, but still
not completely right, because of bugs in gcc-2.96/glibc-2.2.4.

If libunwind segfaults or aborts because of errors in the unwind info,
then that would be a problem for gdb, as that would kill gdb.  It would
be better if libunwind returned an error indication, but it isn't clear
if there is a problem, or whether it is worthwhile to fix.

> Is there any way to detect that the application is not using the new
> unwind structures and therefore we should not attempt to utilize
> libunwind?  Can you even tell what compiler was used in an image? 

There aren't really new unwind structures.  Just bugs in the unwind info
when gcc-2.96/glibc-2.2.4 are used.  These bugs don't cause much trouble
for the built-in gcc unwinder, which is only sufficient for C++ EH, but
they do cause trouble for libunwind which is more powerful than the
built-in gcc unwinder, and thus requires greater accuracy in the unwind
info.  gcc-2.96 predates libunwind, so there was never a chance to make
them work together.

If there is debug info, then you can example the dwarf2 producer string
to find which compiler generated it.  This is probably not very
convenient.
address@hidden gcc]$ readelf -dw a.out | grep producer
     DW_AT_producer    : (indirect string, offset: 0x683): GNU C 3.2
20020903 (Red Hat Linux 8.0 3.2-7)
Otherwise, there is no easy way to get the gcc version number from an
executable.

I don't know enough about glibc to know if you can get its version
number from an executable.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com