From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11535 invoked by alias); 18 Jul 2008 13:03:33 -0000 Received: (qmail 11524 invoked by uid 22791); 18 Jul 2008 13:03:32 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jul 2008 13:03:12 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 280B2982C3; Fri, 18 Jul 2008 13:03:10 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 0587698015; Fri, 18 Jul 2008 13:03:09 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KJpc4-0000lM-Sz; Fri, 18 Jul 2008 09:03:08 -0400 Date: Fri, 18 Jul 2008 13:03:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [FYI] Inlining support, rough patch Message-ID: <20080718130308.GA19045@caradoc.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20080613152754.GA4220@caradoc.them.org> <20080715192020.GB3094@caradoc.them.org> <200807172353.m6HNr1nY015884@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807172353.m6HNr1nY015884@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00362.txt.bz2 Thanks for looking at this. I'll turn this conversation into internals documentation later, no matter what version we end up with. On Fri, Jul 18, 2008 at 01:53:01AM +0200, Mark Kettenis wrote: > I can see why it would be desirable to have inlined functions appear > in a backtrace. And I don't necessarily disagree with doing this > through inlined frames. While they're not real stack frames, they're > not too different from frames we create for leaf calls that don't have > a stack frame of their own. The important question is what the frame > ID for such a frame should be. It seems you use the stack address and > entry point of the function in which the code was inlined. As a > consequence you need to extend the frame ID to distinguish it from > that surrounding frame. I think the correct thing to do is to use the > code address (low address or entry point) of the inlined function and > perhaps the stack pointer at that point to construct the frame ID. I don't think I turned unwinding upside down; in fact I think the unwinder changes are fairly unintrusive, but that may be because I saw the earlier versions of this patch... The only substantive change is the short-circuit test in get_prev_frame_1 to accomodate the upside-down ID construction, which is itself isolated to inline frames. Are there other specific changes that you're worried about, or is it just the ID construction? As for those IDs, I think they're necessary. I'd be delighted to be wrong, so I'll explain the new fields and see if we can find a way to be rid of them. The inline_depth field is necessary because more than one function can begin at a given instruction. For example: volatile int x; int inner (void) { return x; } int mid (void) { return inner(); } int outer (void) { return mid(); } No code will be generated for mid that doesn't come from inner, so there's no code address that can be used to distinguish them. The separate block address and code address, and the use of the enclosing function's stack address, are necessary because of frame_id_stack_eq. Given two frame IDs, there are several places we must be able to find out if they belong to the same real stack frame. I've just eliminated the separate block_addr; we can use code_addr instead, with a few changes elsewhere - including, happily, the elimination of frame_id_stack_eq. That removes the requirement for the inlined frame's ID to have the same stack address as the calling frame, though it still needs a stable stack address. > I think this is doable if the inline unwinder is integrated with the > dwarf2 unwinder, or at least shares code with it. That way the > generic frame unwinding code can stay much the way it is. These > frames probably need to be marked and the unwinding code probably > needs a way to skip them. But that will only have a fairly limited > impact. That would make inlining dependent on .debug_frame. But I don't see why it should be. We get inlining from .debug_info instead, and conceptually there's no reason we couldn't get it from another debug format. While inlined frames no longer need to have the same stack address as their caller, in my latest version, they do still need a stable stack address. The only ways I see to get one are to unwind to the caller and ask it, or to hard-code and enforce a requirement that there be .debug_frame and ask the dwarf2 unwinder directly. The second seems like a special case of the first, so I'm missing the advantage. -- Daniel Jacobowitz CodeSourcery