From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26951 invoked by alias); 22 Aug 2006 20:10:11 -0000 Received: (qmail 26940 invoked by uid 22791); 22 Aug 2006 20:10:10 -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; Tue, 22 Aug 2006 20:10:08 +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 k7MK9WUM028326; Tue, 22 Aug 2006 22:09:32 +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 k7MK9VL5032598; Tue, 22 Aug 2006 22:09:31 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k7MK9Vmu002926; Tue, 22 Aug 2006 22:09:31 +0200 (CEST) Date: Tue, 22 Aug 2006 20:24:00 -0000 Message-Id: <200608222009.k7MK9Vmu002926@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20060820162821.GA20987@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 20 Aug 2006 12:28:21 -0400) Subject: Re: [rfc, frame] Add backtrace stop reasons References: <20060819154646.GA25238@nevyn.them.org> <200608201438.k7KEcJho022644@elgar.sibelius.xs4all.nl> <20060820162821.GA20987@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-08/txt/msg00162.txt.bz2 > Date: Sun, 20 Aug 2006 12:28:21 -0400 > From: Daniel Jacobowitz > > Hi Mark, thanks for looking at these. > > On Sun, Aug 20, 2006 at 04:38:19PM +0200, Mark Kettenis wrote: > > > A nice bonus, in my opinion: if the backtrace stops because unwinding > > > detects an error or the end of the stack, "info frame" will explain > > > why. For instance: > > > > > > Stops backtrace: previous frame inner to this frame (corrupt stack?) > > > > Is this really useful? It adds an extra line to the "info frame" > > output, which might mean that more useful information about the frame > > scrolls of my screen :(. > > (gdb) info frame > Stack level 0, frame at 0xbf8e5838: > eip = 0xffffe410 in __kernel_vsyscall; saved eip 0xb7ea61cb > called by frame at 0xbf8e5850 > Arglist at 0xbf8e5830, args: > Locals at 0xbf8e5830, Previous frame's sp is 0xbf8e5838 > Saved registers: > ebp at 0xbf8e5828, eip at 0xbf8e5834 > > Where are we really in danger of this scrolling off the screen? Frames > with dozens of arguments (which generally wouldn't stop the backtrace > anyway, so wouldn't have the line)? I can imagine reasons to dislike > adding more information, but I confess this one confuses me a bit :-) But you're cheating by choosing an example from a register-starved architecture ;-) Here's the output on 64-bit SPARC: Stack level 2, frame at 0xfffffffffffc8cc0: pc = 0x100a54 in main (../../../../src/gdb/gdb/testsuite/gdb.base/run.c:63); saved pc 0x1007b8 caller of frame at 0xfffffffffffc8bf0 source language c. Arglist at 0xfffffffffffc8cc0, args: argc=2, argv=0xfffffffffffc8e08, envp=0xfffffffffffc8e20 Locals at 0xfffffffffffc8cc0, Previous frame's sp in fp Saved registers: l0 at 0xfffffffffffc8cc0, l1 at 0xfffffffffffc8cc8, l2 at 0xfffffffffffc8cd0, l3 at 0xfffffffffffc8cd8, l4 at 0xfffffffffffc8ce0, l5 at 0xfffffffffffc8ce8, l6 at 0xfffffffffffc8cf0, l7 at 0xfffffffffffc8cf8, i0 at 0xfffffffffffc8d00, i1 at 0xfffffffffffc8d08, i2 at 0xfffffffffffc8d10, i3 at 0xfffffffffffc8d18, i4 at 0xfffffffffffc8d20, i5 at 0xfffffffffffc8d28, fp at 0xfffffffffffc8d30 It's not yet a screenful, but already getting close. I think I've seen even worse on 64-bit MIPS, but indeed it is not too bad yet. But I guess I'd really wanted to point out that we should be careful about printing out too much information. On the other hand we would only print the additionol info for the last frame on the chain. It's my feeling though that "Stops backtrace" does not indicate a property of the frame like the other things we print. But printing something like "Outermost frame: unwinding indicated no return address". sounds better to me. What do other people think? > If you want; there's no point in this unless at least one of the other > patches goes in. > > The problem with holding things until we really need them is that we > build up these huge queues of patches related to a single project. > I'm sure this code wouldn't turn into abandonware. But it's a small > patch, so I can easily carry it along until we're ready for it if you > prefer. I think we can work something out that we both agree on pretty soon, at least for this part Mark