From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15694 invoked by alias); 20 Jun 2009 19:28:13 -0000 Received: (qmail 15682 invoked by uid 22791); 20 Jun 2009 19:28:11 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-gx0-f205.google.com (HELO mail-gx0-f205.google.com) (209.85.217.205) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 20 Jun 2009 19:28:03 +0000 Received: by gxk1 with SMTP id 1so3666503gxk.0 for ; Sat, 20 Jun 2009 12:28:01 -0700 (PDT) Received: by 10.90.53.4 with SMTP id b4mr3432055aga.98.1245526079714; Sat, 20 Jun 2009 12:27:59 -0700 (PDT) Received: from hydrogen.gmail.com (207-172-203-39.c3-0.upd-ubr7.trpr-upd.pa.cable.rcn.com [207.172.203.39]) by mx.google.com with ESMTPS id 26sm2143759aga.64.2009.06.20.12.27.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 12:27:58 -0700 (PDT) Date: Sat, 20 Jun 2009 19:28:00 -0000 Message-ID: <87k536zow5.wl%naesten@gmail.com> From: Samuel Bronson To: Mark Kettenis Cc: tromey@redhat.com, gdb-patches@sourceware.org Subject: Re: [FYI] Inlining support, rough patch In-Reply-To: <200906200956.n5K9ueuN029061@brahms.sibelius.xs4all.nl> 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> <200906200956.n5K9ueuN029061@brahms.sibelius.xs4all.nl> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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: 2009-06/txt/msg00535.txt.bz2 At Sat, 20 Jun 2009 11:56:40 +0200 (CEST), Mark Kettenis wrote: > > > 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. FWIW, there is no "register state for the call site" of an inlined function. The inlined function's variables compete for stack slots and registers with those of the calling function, and their code may be interspersed and re-ordered. The closest thing to "register state for the call site" that exists in this context is, well, the same register state as that seen in the inline function. This doesn't have anything to do with limitations of the debug information, either; the compiler could not have such a concept as "register state for the call site" without seriously compromising the benefits of doing the inlining in the first place. > > 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.