This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [6.2] PROBLEMS file
- From: "Eli Zaretskii" <eliz at gnu dot org>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 19 Jul 2004 21:51:27 +0200
- Subject: Re: [6.2] PROBLEMS file
- References: <40FB3F1F.3040900@gnu.org>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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.
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.
Unfortunately, I didn't have enough time to debug this (one or two
attempts to find the reason didn't succeed, as I got bogged down in
the maze of frame-related function calls that jump back and forth
between platform-independent and target-specific code).