From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14152 invoked by alias); 21 Jul 2004 21:05:16 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14134 invoked from network); 21 Jul 2004 21:05:13 -0000 Received: from unknown (HELO copland.kettenis.dyndns.org) (82.74.7.234) by sourceware.org with SMTP; 21 Jul 2004 21:05:13 -0000 Received: from copland.kettenis.dyndns.org (kettenis@localhost.kettenis.dyndns.org [127.0.0.1]) by copland.kettenis.dyndns.org (8.13.0/8.13.0) with ESMTP id i6LKxhpr011577; Wed, 21 Jul 2004 22:59:43 +0200 (CEST) Received: (from kettenis@localhost) by copland.kettenis.dyndns.org (8.13.0/8.13.0/Submit) id i6LKxgQ9019045; Wed, 21 Jul 2004 22:59:42 +0200 (CEST) Date: Wed, 21 Jul 2004 21:12:00 -0000 Message-Id: <200407212059.i6LKxgQ9019045@copland.kettenis.dyndns.org> From: Mark Kettenis To: eliz@gnu.org CC: cagney@gnu.org, gdb@sources.redhat.com In-reply-to: <1659-Mon19Jul2004215127+0300-eliz@gnu.org> Subject: Re: [6.2] PROBLEMS file References: <40FB3F1F.3040900@gnu.org> <1659-Mon19Jul2004215127+0300-eliz@gnu.org> X-SW-Source: 2004-07/txt/msg00270.txt.bz2 Date: Mon, 19 Jul 2004 21:51:27 +0200 From: "Eli Zaretskii" > Date: Sun, 18 Jul 2004 23:25:19 -0400 > From: Andrew Cagney > > 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