This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Indicating function exit points in debug data
On Thu, 21 Mar 2019 at 09:11, Justin Paston-Cooper
<paston.cooper@gmail.com> wrote:
>
> On Thu, 21 Mar 2019 at 08:23, Richard Biener <richard.guenther@gmail.com> wrote:
> >
> > On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey <tom@tromey.com> wrote:
> > >
> > > >>>>> "Segher" == Segher Boessenkool <segher@kernel.crashing.org> 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?
I've looked at function.c a bit more, and I see what Segher is getting
at. Also, given that a function might have multiple return statements
pointing to a single 'ret' instruction, I'm not sure that 'ret' is the
best solution. I also see that there will only be a single epilogue,
so that would not be useful either.
>
> >
> > Richard.
> >
> > > thanks,
> > > Tom