Binutils actions? binutils/debug.c miscompiled with 2.95.4 < gcc < 3.0.2 in i386/ia32.

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

(CC to gcc-bugs mostly for archival purposes; I'll see if
there's a test-case covering this bug.)

The externally visible behavior is that "objdump --debugging
libc.so.6" and "objdump --debugging ld-linux.so.2" (with an
unstripped DSO) does not exit, but "hangs" after partial output,
seemingly half-way.  I don't have a short test-case for the
debug info present to see this.  It might be easy: debug info
for two structures to compare for the same type contents is
necessary.  Note that it seems Debian usually strips its DSO:s.

The bug is in (at least) i?86 (ia32, i386, whatever, versions of):
egcs-1.1.2 (RH 6.2)
"gcc version 2.95.2 20000220 (Debian GNU/Linux)"
 (Debian 2.2)
gcc-2.95.3 (stock)
"gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)"
 (No need to inform me about the non-official state of that
  compiler)
"gcc version 2.95.4 20011006 (Debian prerelease)"
 (as Debian (3.0) calls it for similarly bad and good reasons)

It's fixed in gcc-3.0.2 (stock) and CVS HEAD of a few hours ago.

As mentioned, you'll see this for native binutils on
i?86-pc-linux-gnu, but also for cross-tools to (I think) from
that platform to any platform that uses stabs, but not
necessarily restricted to stabs, FWIW.  Certainly it happens for
cris-axis-linux-gnu.  I don't see it on sparc-sun-solaris2.8
with gcc version 2.95.2 19991024 (release).

The internally visible behavior is that debug_get_real_type in
binutils/binutils/debug.c is miscompiled.  The recursive calls
in that function are (incorrectly) optimized to tail-calls, so
room for "struct debug_type_real_list rl" isn't allocated, and
it's overwritten.  For some constructs present in the DSO:s
above, the overwrite forms a loop in the linked list, and the
for-loop in that function that is supposed to terminate at the
end of the linked
list to its end, does not terminate.

This file, binutils/debug.c, hasn't changed in any significant
aspect since it was initially imported in 1999; essentially the
source in binutils CVS HEAD is the same in binutils-2.10 and
binutils-2.11 (branches).

Now the question: should we (if you want, read I) add some
work-around in binutils for this?  On one hand, this isn't
life-support-level functionality, though when searching I see
people *have* reported this before (it seems), and even
diagnosed it correctly, but nothing further:
<URL:http://sources.redhat.com/ml/bug-binutils/2001-q4/msg00155.html>.
Also, work-arounds are bad, m'kay.  On the other hand these are
popular releases/distributions of GNU software and gcc-3.0.2
isn't universal.

FWIW, inserting calls to dummy functions after the recursive
call is effective.  Another attempt, initializing the struct, is
not a "correct" work-around; it just stops a loop from being
formed; output may be affected compared to valid code.

brgds, H-P