This is the mail archive of the
mailing list for the binutils project.
Binutils actions? binutils/debug.c miscompiled with 2.95.4 < gcc < 3.0.2 in i386/ia32.
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: binutils at sources dot redhat dot com
- Cc: gcc-bugs at gcc dot gnu dot org, gwpt1 at cam dot ac dot uk, orjan dot friberg at axis dot com
- Date: Wed, 19 Dec 2001 04:22:06 +0100
- Subject: Binutils actions? binutils/debug.c miscompiled with 2.95.4 < gcc < 3.0.2 in i386/ia32.
(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)"
"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
"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
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:
Also, work-arounds are bad, m'kay. On the other hand these are
popular releases/distributions of GNU software and gcc-3.0.2
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.