From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87598 invoked by alias); 21 Mar 2019 09:11:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 86920 invoked by uid 89); 21 Mar 2019 09:11:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:CAFiYyc, H*f:UTUz34tR-NF, H*f:sk:qEhg@ma, H*f:wcPu6kAH X-HELO: mail-io1-f51.google.com Received: from mail-io1-f51.google.com (HELO mail-io1-f51.google.com) (209.85.166.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Mar 2019 09:11:55 +0000 Received: by mail-io1-f51.google.com with SMTP id d201so101590iof.7 for ; Thu, 21 Mar 2019 02:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vwXkvFRlPJEl/vLU2EC08OnMKYbCGz+xetMD+95Bq00=; b=svMEP3ohDLOoyhfCSlK3zCPYspCQU49VgRD34DZDUBCSHESN5ilz0WpGq8hv3PiKfc J/wUrsqXIKOHETrHGUwol1RUDGx4DG6m6oCGCGw8xJzYS8Nngyc2NTUR4VDXqIWotUyi Lt0qr2fap2vuPuxSglc/dMUOyu7XKw+4eWy8grLjw9P78iK+76Br0m/4OPD1qo/ZyQ14 rc49MzTnw05AYPVuXxgD2Ji7bdK+eftcwRM5kCCHL+P7TJdIOP5RBLHcpauaF4uv/q+c Y1l6CIabEvc09rXAwj6ogVwY5Is8EnKprWUiRbxi2no1B9Pw+5JMGUbezfkNgMDWIar2 mUIQ== MIME-Version: 1.0 References: <20190320173633.GB3969@gate.crashing.org> <87o965pdsd.fsf@tromey.com> In-Reply-To: From: Justin Paston-Cooper Date: Thu, 21 Mar 2019 09:11:00 -0000 Message-ID: Subject: Re: Indicating function exit points in debug data To: Richard Biener Cc: Tom Tromey , Segher Boessenkool , GCC Development Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-03/txt/msg00153.txt.bz2 On Thu, 21 Mar 2019 at 08:23, Richard Biener wrote: > > On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey wrote: > > > > >>>>> "Segher" == Segher Boessenkool writes: > > > > >> Section 6.2.5.2 outlines the line number information state machine's > > >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition > > >> is: > > > > Segher> How should this work with shrink-wrapping? The whole point of that is > > Segher> you do not tear down the frame after all other code, etc. I don't see > > Segher> how we can do better than putting this DW_LNS_set_epilogue_begin right > > Segher> before the actual return -- and that is after all the tear down etc. > > > > I think it's fine if the epilogue marker is inexact or missing from > > optimized code, because (1) that's the current state, and (2) it doesn't > > really make sense to talk about an epilogue in some cases. > > > > Similarly, IMO it is fine not to worry about non-local exits. You can > > already catch exceptions and examine them in gdb -- the epilogue marker > > feature is mostly to address the unmet need of wanting to set a > > breakpoint at the end of a function. > > Btw, the feature I am missing is not breaking at the end of a function > but conditionally breaking on a specific return value of a specific function. > Those are probably related but my usecase might be easier because > the return value location is defined by the ABI and catching the actual > return assembly instruction should already work. > > > Ideally, in -O0 / -Og code, the marker would be reliable where it > > appears. > > > > It would be great if there was a way to indicate the location of the > > value-to-be-returned in the DWARF. That way gdb could extract it at the > > epilogue point. AFAIK this would require a DWARF extension. > > The ABI specifies this at the 'ret' instruction? Would this still allow inspection of the function's final state, where it returns, apart from its return value? That is the original behaviour I had in mind. Also for completeness it would be nice if this feature supported inline functions too. 'ret' would not be a solution for that. From what Segher said, I understand that the 'epilogue_begin' marker is put right before the 'ret' instruction if it exists. Does gdb have another way of finding the real epilogue beginning, before registers are restored? > > Richard. > > > thanks, > > Tom