From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20364 invoked by alias); 17 Jul 2008 23:53:27 -0000 Received: (qmail 20355 invoked by uid 22791); 17 Jul 2008 23:53:26 -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; Thu, 17 Jul 2008 23:53:09 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id m6HNr14j030571; Fri, 18 Jul 2008 01:53:01 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id m6HNr1nY015884; Fri, 18 Jul 2008 01:53:01 +0200 (CEST) Date: Thu, 17 Jul 2008 23:53:00 -0000 Message-Id: <200807172353.m6HNr1nY015884@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20080715192020.GB3094@caradoc.them.org> (message from Daniel Jacobowitz on Tue, 15 Jul 2008 15:20:20 -0400) Subject: Re: [FYI] Inlining support, rough patch References: <20080613152754.GA4220@caradoc.them.org> <20080715192020.GB3094@caradoc.them.org> 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/msg00358.txt.bz2 > Date: Tue, 15 Jul 2008 15:20:20 -0400 > From: Daniel Jacobowitz > > I'm looking for any comments on the patch itself, test coverage on > different systems (of both the patch and its included test cases), and > for people to try it and tell me whether it works naturally or if any > of my design choices seem wrong. I don't know of any bugs in the GDB > patch, although there are some limitations (see the new manual > chapter). Beware, though, it makes GDB more sensitive to incorrect > debug info from GCC. OK, I've looked a bit more at this diff, but I don't think I completely understand it yet. I really, really, don't like the way you turn the frame unwinding completely upside down though. Im afraid that to me, thist suggests that your approach is seriously flawed. Another indication is that you seem to need state for the inline unwinder. 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 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.