This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [6.2] PROBLEMS file
Date: Mon, 19 Jul 2004 21:51:27 +0200
From: "Eli Zaretskii" <eliz@gnu.org>
> Date: Sun, 18 Jul 2004 23:25:19 -0400
> From: Andrew Cagney <cagney@gnu.org>
>
> gdb/1505: [regression] gdb prints a bad backtrace for a thread
>
> When backtracing a thread, gdb does not stop when it reaches the
> outermost frame, instead continuing until it hits garbage. This is
> sensitive to the operating system and thread library.
In most cases there is no way for GDB to tell what the outermost frame
is. Some people think that %ebp == 0 or %eip == 0 serves as a marker,
but they're mistaken. The usage as %ebp as a frame pointer is a
software comvention which isn't mandated by the ABI. More and more
code doesn't use %ebp as a frame pointer, makeing that register
available for other purposes. In that case, %ebp == 0 defenitely
shouldn't terminate the backtrace. And %eip == 0 can happen in the
case of a null-pointer function call.
FWIW, I've seen similar problems without any threading, in the DJGPP
port (when debugging Emacs). GDB 5.x doesn't have problems with the
same debuggee. I originally thought that it is specific to DJGPP
(perhaps because the DJGPP port of Emacs is compiled with -gcoff and
the line number table overflows the 64K limit inherent to COFF debug
info), but now that I see this PR, I begin to think that it's not
DJGPP-specific.
We'll just have to live with this. The days where we could trust the
"frame chain" on the i386 are over; there is too much frameless code
out there, and it will only increase. Without DWARF2 CFI we have to
rely on the prologue analyzer to properly unwind the stack. There
certainly is room for improvement in the prologue analyzer, but it
will probably never be perfect. There will always be cases where GDB
will get confused and lose track. In that case it will possibly
provide an endless or very long backtrace containing garbage.
So IMHO there is no regression here. PR 1505 should be closed. If
the length of the backtraces is a problem, we should probably set a
sensible backtrace limit.
Mark