From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20133 invoked by alias); 20 Jun 2009 09:57:07 -0000 Received: (qmail 20125 invoked by uid 22791); 20 Jun 2009 09:57:06 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 20 Jun 2009 09:57:00 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n5K9ufLe031329; Sat, 20 Jun 2009 11:56:41 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n5K9ueuN029061; Sat, 20 Jun 2009 11:56:40 +0200 (CEST) Date: Sat, 20 Jun 2009 09:57:00 -0000 Message-Id: <200906200956.n5K9ueuN029061@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: tromey@redhat.com CC: gdb-patches@sourceware.org In-reply-to: (message from Tom Tromey on Thu, 18 Jun 2009 11:55:42 -0600) Subject: Re: [FYI] Inlining support, rough patch References: <20080613152754.GA4220@caradoc.them.org> <20080715192020.GB3094@caradoc.them.org> <200807172353.m6HNr1nY015884@brahms.sibelius.xs4all.nl> <20080718130308.GA19045@caradoc.them.org> <200807251446.m6PEkfwc027635@brahms.sibelius.xs4all.nl> <20080725174636.GB2433@caradoc.them.org> <200903312042.n2VKgIUx003764@brahms.sibelius.xs4all.nl> <20090420154909.GA5386@caradoc.them.org> <200904222203.n3MM3Wo5001785@brahms.sibelius.xs4all.nl> <20090423124839.GA4556@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: 2009-06/txt/msg00530.txt.bz2 > From: Tom Tromey > Date: Thu, 18 Jun 2009 11:55:42 -0600 > > Ping. > > Mark> I firmly believe that if we want to add the capability to unwind > Mark> through inlined functions, this fundamental principle should hold for > Mark> inlined functions as well. This means that if we can detect that the > Mark> current register state describes a process executing an inlined > Mark> function we should faithfully reconstruct the register state for the > Mark> call site of that inlined function. If I understand things correctly, > Mark> the DW_TAG_inlined_subroutine tag provides information about the call > Mark> site, which gives us the unwound program counter. But in order to > Mark> reconstruct the complete register state, we need more information. > Mark> The only viable source of that information is something like DWARF > Mark> CFI; you don't stand a chance of doing a proper job here by doing > Mark> instruction analysis. > > Daniel> DWARF CFI is not going to help with this; it only deals with 'real' > Daniel> (i.e. not inlined) functions. There's no saved register state > Daniel> from the virtual entry point. There isn't even an indicator > Daniel> of where inlining occurs. Are you suggesting enhancing > Daniel> the CFI information? I suspect the extra register state > Daniel> would be generally unretrievable. > > It has been two months since this response. I think Daniel addressed > your objections, at least to the extent they are addressable given the > existing Dwarf specification. > > I would like it if this patch did not stay in limbo any longer. I > think that goes for others, too: according to Joel's summit notes, > this patch was explicitly asked about by attendees. > > At a minimum, could you answer his question above? Thanks. Sorry, I have been travelling for the last month. I still think the inline unwinder should not bend the rules we established for unwinders. But since I'm obviously not capable of coming up with a better way to do this, please use your own judgements about this diff.