Re: Indicating function exit points in debug data

[Justin Paston-Cooper <paston.cooper@gmail.com>]

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.