Indicating function exit points in debug data

Indicating function exit points in debug data

[Justin Paston-Cooper]

Hello,

In my message https://sourceware.org/ml/gdb/2019-03/msg00042.html to
the gdb mailing list, I asked whether it would be possible to
implement a command which breaks at all exit points of the current
stack frame. This would be very useful for evaluating a function's
final state before it returns its result, independent of where in its
definition it returns from.

Tom Tromey suggested in that thread that this would be quite easy on
gdb's side if gcc indicates exit locations in the DWARF data, for
instance in the C case, it would indicate the locations of return
statements. On a related note, he mentions that the "finish" command
does not work for inlined functions because the compiler does not emit
the required information.

It would be nice if this new break on exit command worked both for
inlined functions, and also the case of breaking after tail-recursions
exit. With a single stone, the "finish" bird above is also killed.

Would it be feasible to implement such a feature in gcc? If I'm not
the first person to ask for this, are there any architectural or
practical reasons as to why it might not be possible to implement? As
it stands, I don't have the level of familiarity with gcc to come to
you with a patch, but with guidance I would certainly be interested in
working on the C/C++ case if that would be useful.

Thanks,

Justin

Re: Indicating function exit points in debug data

[Florian Weimer]

* Justin Paston-Cooper:

> Tom Tromey suggested in that thread that this would be quite easy on
> gdb's side if gcc indicates exit locations in the DWARF data, for
> instance in the C case, it would indicate the locations of return
> statements. On a related note, he mentions that the "finish" command
> does not work for inlined functions because the compiler does not emit
> the required information.

What about calls to noreturn functions?  I assume they would need
breakpoints as well.  It could be tricky if those are only called
indirectly, I assume.

Re: Indicating function exit points in debug data

[Justin Paston-Cooper]

On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Justin Paston-Cooper:
>
> > Tom Tromey suggested in that thread that this would be quite easy on
> > gdb's side if gcc indicates exit locations in the DWARF data, for
> > instance in the C case, it would indicate the locations of return
> > statements. On a related note, he mentions that the "finish" command
> > does not work for inlined functions because the compiler does not emit
> > the required information.
>
> What about calls to noreturn functions?  I assume they would need
> breakpoints as well.  It could be tricky if those are only called
> indirectly, I assume.

Couldn't the brace following the final line of an inlined noreturn
function be viewed as its exit point and be indicated in the DWARF
information accordingly? Is the problem that each entry in the line
number table has to point to a specific statement? Could you explain
what you mean with "indirectly"?

Re: Indicating function exit points in debug data

[Florian Weimer]

* Justin Paston-Cooper:

> On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>> * Justin Paston-Cooper:
>>
>> > Tom Tromey suggested in that thread that this would be quite easy on
>> > gdb's side if gcc indicates exit locations in the DWARF data, for
>> > instance in the C case, it would indicate the locations of return
>> > statements. On a related note, he mentions that the "finish" command
>> > does not work for inlined functions because the compiler does not emit
>> > the required information.
>>
>> What about calls to noreturn functions?  I assume they would need
>> breakpoints as well.  It could be tricky if those are only called
>> indirectly, I assume.
>
> Couldn't the brace following the final line of an inlined noreturn
> function be viewed as its exit point and be indicated in the DWARF
> information accordingly?

That breakpoint would never be reached.

> Is the problem that each entry in the line
> number table has to point to a specific statement? Could you explain
> what you mean with "indirectly"?

In C++, a function might return to the caller by calling *another*
function which throws an exception.

Similarly, in C, a function could call a function that in turn calls
longjmp.

Or more prosaically, a called function might call the exit function.

I'm just wondering if such abnormal exits should be covered as well,
and calling a noreturn function could be a reasonable indicator.

Re: Indicating function exit points in debug data

[Justin Paston-Cooper]

On Tue, 19 Mar 2019 at 21:52, Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Justin Paston-Cooper:
>
> > On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de> wrote:
> >>
> >> * Justin Paston-Cooper:
> >>
> >> > Tom Tromey suggested in that thread that this would be quite easy on
> >> > gdb's side if gcc indicates exit locations in the DWARF data, for
> >> > instance in the C case, it would indicate the locations of return
> >> > statements. On a related note, he mentions that the "finish" command
> >> > does not work for inlined functions because the compiler does not emit
> >> > the required information.
> >>
> >> What about calls to noreturn functions?  I assume they would need
> >> breakpoints as well.  It could be tricky if those are only called
> >> indirectly, I assume.
> >
> > Couldn't the brace following the final line of an inlined noreturn
> > function be viewed as its exit point and be indicated in the DWARF
> > information accordingly?
>
> That breakpoint would never be reached.

Then if the break on exit command would break on return statements of
functions which return, then it could break on the final statement of
a noreturn?

>
> > Is the problem that each entry in the line
> > number table has to point to a specific statement? Could you explain
> > what you mean with "indirectly"?
>
> In C++, a function might return to the caller by calling *another*
> function which throws an exception.
>
> Similarly, in C, a function could call a function that in turn calls
> longjmp.
>
> Or more prosaically, a called function might call the exit function.
>
> I'm just wondering if such abnormal exits should be covered as well,
> and calling a noreturn function could be a reasonable indicator.

Re: Indicating function exit points in debug data

[Florian Weimer]

* Justin Paston-Cooper:

> On Tue, 19 Mar 2019 at 21:52, Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>> * Justin Paston-Cooper:
>>
>> > On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de> wrote:
>> >>
>> >> * Justin Paston-Cooper:
>> >>
>> >> > Tom Tromey suggested in that thread that this would be quite easy on
>> >> > gdb's side if gcc indicates exit locations in the DWARF data, for
>> >> > instance in the C case, it would indicate the locations of return
>> >> > statements. On a related note, he mentions that the "finish" command
>> >> > does not work for inlined functions because the compiler does not emit
>> >> > the required information.
>> >>
>> >> What about calls to noreturn functions?  I assume they would need
>> >> breakpoints as well.  It could be tricky if those are only called
>> >> indirectly, I assume.
>> >
>> > Couldn't the brace following the final line of an inlined noreturn
>> > function be viewed as its exit point and be indicated in the DWARF
>> > information accordingly?
>>
>> That breakpoint would never be reached.
>
> Then if the break on exit command would break on return statements of
> functions which return, then it could break on the final statement of
> a noreturn?

There's no final statement in a noreturn function because it will
never return.  It either has an endless loop, or it calls another
noreturn function (which is at a certain point opaque to the compiler)
which never returns.

Sorry, I have a fealing we are talking past each other.  With
“noreturn function”, I mean a function that is annotated with the
noreturn attribute:

<https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute>

Re: Indicating function exit points in debug data

[Justin Paston-Cooper]

On Tue, 19 Mar 2019 at 22:40, Florian Weimer <fw@deneb.enyo.de> wrote:

> * Justin Paston-Cooper:
>
> > On Tue, 19 Mar 2019 at 21:52, Florian Weimer <fw@deneb.enyo.de> wrote:
> >>
> >> * Justin Paston-Cooper:
> >>
> >> > On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de>
> wrote:
> >> >>
> >> >> * Justin Paston-Cooper:
> >> >>
> >> >> > Tom Tromey suggested in that thread that this would be quite easy
> on
> >> >> > gdb's side if gcc indicates exit locations in the DWARF data, for
> >> >> > instance in the C case, it would indicate the locations of return
> >> >> > statements. On a related note, he mentions that the "finish"
> command
> >> >> > does not work for inlined functions because the compiler does not
> emit
> >> >> > the required information.
> >> >>
> >> >> What about calls to noreturn functions?  I assume they would need
> >> >> breakpoints as well.  It could be tricky if those are only called
> >> >> indirectly, I assume.
> >> >
> >> > Couldn't the brace following the final line of an inlined noreturn
> >> > function be viewed as its exit point and be indicated in the DWARF
> >> > information accordingly?
> >>
> >> That breakpoint would never be reached.
> >
> > Then if the break on exit command would break on return statements of
> > functions which return, then it could break on the final statement of
> > a noreturn?
>
> There's no final statement in a noreturn function because it will
> never return.  It either has an endless loop, or it calls another
> noreturn function (which is at a certain point opaque to the compiler)
> which never returns.
>
> Sorry, I have a fealing we are talking past each other.  With
> “noreturn function”, I mean a function that is annotated with the
> noreturn attribute:
>
> <
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute
> >


> Sorry about that, and thanks for the link. I jumped to conclusions with
regards to the meaning of noreturn.

Re: Indicating function exit points in debug data

[Richard Biener]

On Tue, Mar 19, 2019 at 9:38 PM Justin Paston-Cooper
<paston.cooper@gmail.com> wrote:
>
> Hello,
>
> In my message https://sourceware.org/ml/gdb/2019-03/msg00042.html to
> the gdb mailing list, I asked whether it would be possible to
> implement a command which breaks at all exit points of the current
> stack frame. This would be very useful for evaluating a function's
> final state before it returns its result, independent of where in its
> definition it returns from.
>
> Tom Tromey suggested in that thread that this would be quite easy on
> gdb's side if gcc indicates exit locations in the DWARF data, for

Did he indicate _how_ to represent this in DWARF?  I suppose the breakpoint
should happen before the local frame is teared down.

> instance in the C case, it would indicate the locations of return
> statements. On a related note, he mentions that the "finish" command
> does not work for inlined functions because the compiler does not emit
> the required information.

While "finish" wants a location at the caller side, after the inlined frame is
teared down.  So they are somewhat distinct.

Can you open two enhancement requests in buzilla?

Thanks,
Richard.

> It would be nice if this new break on exit command worked both for
> inlined functions, and also the case of breaking after tail-recursions
> exit. With a single stone, the "finish" bird above is also killed.

> Would it be feasible to implement such a feature in gcc? If I'm not
> the first person to ask for this, are there any architectural or
> practical reasons as to why it might not be possible to implement? As
> it stands, I don't have the level of familiarity with gcc to come to
> you with a patch, but with guidance I would certainly be interested in
> working on the C/C++ case if that would be useful.
>
> Thanks,
>
> Justin

Re: Indicating function exit points in debug data

[Justin Paston-Cooper]

On Wed, 20 Mar 2019 at 08:31, Richard Biener <richard.guenther@gmail.com> wrote:
>
> On Tue, Mar 19, 2019 at 9:38 PM Justin Paston-Cooper
> <paston.cooper@gmail.com> wrote:
> >
> > Hello,
> >
> > In my message https://sourceware.org/ml/gdb/2019-03/msg00042.html to
> > the gdb mailing list, I asked whether it would be possible to
> > implement a command which breaks at all exit points of the current
> > stack frame. This would be very useful for evaluating a function's
> > final state before it returns its result, independent of where in its
> > definition it returns from.
> >
> > Tom Tromey suggested in that thread that this would be quite easy on
> > gdb's side if gcc indicates exit locations in the DWARF data, for
>
> Did he indicate _how_ to represent this in DWARF?  I suppose the breakpoint
> should happen before the local frame is teared down.

Tom didn't suggest any specific implementation. Simon Marchi in the
same thread said, "I suppose that the list of all function exit points
(regardless of whether it is a jump or real return) is an information
that the compiler could theoretically produce and encode in the DWARF
information?". I had a look at the DWARF5 specification. Section 6.2.2
outlines the registers of the state machine which deals with line
number information. One of those registers is named "epilogue_begin".
Its definition is:

-----
A boolean indicating that the current address is one (of possibly
many) where execution should be suspended for a breakpoint just prior
to the exit of a function.
-----

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:

-----
The DW_LNS_set_epilogue_begin opcode takes no operands. It sets the
epilogue_begin register to “true”. When a breakpoint is set on the
exit of a function or execution steps over the last executable
statement of a function, it is generally desirable to suspend
execution after completion of the last statement but prior to tearing
down the frame (so that local variables can still be examined).
Debuggers generally cannot properly determine where this point is.
This command allows a compiler to communicate the location(s) to use.
Note that the function to which the epilogue end applies cannot be
directly determined from the line number information alone; it must be
determined in combination with the subroutine information entries of
the compilation (including inlined subroutines). In the case of a
trivial function, both prologue end and epilogue begin may occur at
the same address.
-----

Shouldn't this be sufficient for gdb to work backwards and determine
the _beginning_ of any exit statement of a function? I had a look into
gcc's involvement with "epilogue_begin". The pass called
"pass_thread_prologue_and_epilogue" transitively calls a function
defined in function.c called "make_epilogue_seq", which as far as I
understand emits an "epilogue_begin" note. I'm not sure how this pass
ties in with each frontend. Does a frontend need to support this pass
explicitly? If so, is it just not supported by a lot of frontends?
Given that no one on the gdb thread mentioned this pass, is there
another problem which I am not aware of?

>
> > instance in the C case, it would indicate the locations of return
> > statements. On a related note, he mentions that the "finish" command
> > does not work for inlined functions because the compiler does not emit
> > the required information.
>
> While "finish" wants a location at the caller side, after the inlined frame is
> teared down.  So they are somewhat distinct.

Obviously I'm not familiar with gcc/gdb internals, but superficially
my idea was that if 'finish' has access to the information on the exit
points of an inlined function, then it can keep track of which
register/location the "return" value ends up in.

>
> Can you open two enhancement requests in buzilla?

Will do.

>
> Thanks,
> Richard.
>
> > It would be nice if this new break on exit command worked both for
> > inlined functions, and also the case of breaking after tail-recursions
> > exit. With a single stone, the "finish" bird above is also killed.
>
> > Would it be feasible to implement such a feature in gcc? If I'm not
> > the first person to ask for this, are there any architectural or
> > practical reasons as to why it might not be possible to implement? As
> > it stands, I don't have the level of familiarity with gcc to come to
> > you with a patch, but with guidance I would certainly be interested in
> > working on the C/C++ case if that would be useful.
> >
> > Thanks,
> >
> > Justin

Re: Indicating function exit points in debug data

[Segher Boessenkool]

On Wed, Mar 20, 2019 at 10:13:23AM +0000, Justin Paston-Cooper wrote:
> 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:
> 
> -----
> The DW_LNS_set_epilogue_begin opcode takes no operands. It sets the
> epilogue_begin register to “true”. When a breakpoint is set on the
> exit of a function or execution steps over the last executable
> statement of a function, it is generally desirable to suspend
> execution after completion of the last statement but prior to tearing
> down the frame (so that local variables can still be examined).
> Debuggers generally cannot properly determine where this point is.
> This command allows a compiler to communicate the location(s) to use.
> Note that the function to which the epilogue end applies cannot be
> directly determined from the line number information alone; it must be
> determined in combination with the subroutine information entries of
> the compilation (including inlined subroutines). In the case of a
> trivial function, both prologue end and epilogue begin may occur at
> the same address.
> -----

How should this work with shrink-wrapping?  The whole point of that is
you do not tear down the frame after all other code, etc.  I don't see
how we can do better than putting this DW_LNS_set_epilogue_begin right
before the actual return -- and that is after all the tear down etc.

> I had a look into
> gcc's involvement with "epilogue_begin". The pass called
> "pass_thread_prologue_and_epilogue" transitively calls a function
> defined in function.c called "make_epilogue_seq", which as far as I
> understand emits an "epilogue_begin" note. I'm not sure how this pass
> ties in with each frontend. Does a frontend need to support this pass
> explicitly?

Nope.  This pass is very late in the backend, after register allocation
and everything.  A frontend will just make functions "return", and that's
all it has to do.


Segher

Re: Indicating function exit points in debug data

[Tom Tromey]

>>>>> "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.

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.

thanks,
Tom

Re: Indicating function exit points in debug data

[Richard Biener]

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

Re: Indicating function exit points in debug data

[Justin Paston-Cooper]

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?

>
> Richard.
>
> > thanks,
> > Tom

Re: Indicating function exit points in debug data

[Justin Paston-Cooper]

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