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 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?
Richard.
> thanks,
> Tom