From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32630 invoked by alias); 13 May 2006 09:47:14 -0000 Received: (qmail 32612 invoked by uid 22791); 13 May 2006 09:47:13 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 May 2006 09:47:10 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k4D9ka6W017759; Sat, 13 May 2006 11:46:36 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k4D9kZJU026559; Sat, 13 May 2006 11:46:35 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k4D9kZ2M001331; Sat, 13 May 2006 11:46:35 +0200 (CEST) Date: Sat, 13 May 2006 10:14:00 -0000 Message-Id: <200605130946.k4D9kZ2M001331@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20060510180312.GA12606@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 10 May 2006 14:03:12 -0400) Subject: Re: [RFC] Move the frame zero PC check earlier References: <20060510180312.GA12606@nevyn.them.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00284.txt.bz2 > Date: Wed, 10 May 2006 14:03:12 -0400 > From: Daniel Jacobowitz > > In this patch: > > http://sourceware.org/ml/gdb-patches/2004-12/msg00328.html > > Andrew added a generic check for two "normal" frames in a row where the > older one has a saved PC of zero. This is pretty well understood as a > convention for terminating backtraces - either intentionally or > unintentionally. > > The problem is, given where that check takes place, it is in my opinion one > frame off from the actual problem. You get backtraces that look like this: > > (gdb) bt > #0 catcher (sig=11) at /space/fsf/commit/src/gdb/testsuite/gdb.base/savedregs.c:43 > #1 0x00002ac148ec6e90 in killpg () from /lib/libc.so.6 > #2 0x0000000000000000 in ?? () > > On the one hand, that third frame is a nice marker for this case in that it > explains noisily that GDB is confused. In this case, if I point GDB at > .debug_frame data for my C library (conveniently found by default in > /usr/lib/debug) it successfully backtraces through to main, so that's good. And this is exactly the reason why things are done the way they are done. People should accept that the unwinder can fail, and we should provide a way to indicate this. There are many ways in which an unwinder can fail and they're not always detectable. One very important scemario is where your program is thrashing the stack, overwriting the return address. We absulutely need to provide the user some indication that something is wrong. Currently this is the extra frame we're printing. > On the other hand, that third frame is ugly and generally useless While the third frame itself doesn't provide any useful information, its presence is very useful, since it indicates that GDB has lost track.. > The attached patch moves the check one frame earlier, so that we > only get this backtrace: > > #0 catcher (sig=11) at /space/fsf/commit/src/gdb/testsuite/gdb.base/savedregs.c:43 > #1 0x00002ac148ec6e90 in killpg () from /lib/libc.so.6 > > Benefits: cleaner looking backtraces; the check is only done once per frame > instead of on every call to get_prev_frame. Disadvantages: for all frames > at level > 0, it causes this check to be done when we look at THIS frame > instead of when we unwind to the PREV frame, which forces us to locate the > correct sniffer earlier. If you have a sigtramp sniffer which reads memory, > this might cause an extra memory read. However, it won't happen in the > critical stepping path - we don't need this check when "unwinding frame 0 > from the sentinel frame - so I think this is an acceptable tradeoff. For > any frame other than the top frame, the thing you're most likely to do with > it is backtrace right through it. > > Tested on x86_64-pc-linux-gnu, and by hand against SymbianOS, where it gives > much nicer looking backtraces. Our goal shouldn't be nicer looking backtraces. It should be providing the user with all information needed to fix bugs in their programs. Your patch is removing such a bit of information, and therefore unacceptable to me. Sorry :(. Mark