From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26088 invoked by alias); 18 Jun 2009 17:55:58 -0000 Received: (qmail 26079 invoked by uid 22791); 18 Jun 2009 17:55:58 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Jun 2009 17:55:46 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5IHtjxr005397; Thu, 18 Jun 2009 13:55:45 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5IHtiUw030484; Thu, 18 Jun 2009 13:55:44 -0400 Received: from opsy.redhat.com (vpn-14-1.rdu.redhat.com [10.11.14.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5IHthXD013832; Thu, 18 Jun 2009 13:55:43 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id D74C73784B7; Thu, 18 Jun 2009 11:55:42 -0600 (MDT) To: Mark Kettenis Cc: gdb-patches@sourceware.org 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> From: Tom Tromey Reply-To: tromey@redhat.com Date: Thu, 18 Jun 2009 17:55:00 -0000 In-Reply-To: <20090423124839.GA4556@caradoc.them.org> (Daniel Jacobowitz's message of "Thu\, 23 Apr 2009 08\:48\:39 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00486.txt.bz2 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. Tom