On Tue, Jun 26, 2018 at 01:39:18PM +0200, Florian Weimer wrote:
> > The @code{noreturn} keyword does not affect the exceptional path
> > when that applies: a @code{noreturn}-marked function may still
> > return to the caller by throwing an exception or calling
> > @code{longjmp}.
> >
> > IIRC, in gcc-land you have to give both noreturn and nothrow attributes
> > to make it non-unwindable.
>
> Are you sure? I was under the impression that GCC did not do this because
> it interferes too much with debugging.
>
> Furthermore, glibc marks abort as nothrow and noreturn, which is a bit
> dubious, considering that it is perfectly fine to throw exception from
> synchronously delivered signals.
There is unwindable and unwindable. The default on many target is
-fasynchronous-unwind-tables, where at every instruction .eh_frame contains
everything needed to unwind. nothrow is only about .gcc_except_table if
there is some unwind region etc. So you can still do _Unwind_Backtrace if
you have noexcept functions.
I don't see what is of interest on noreturn functions, either the calls
them, then you have unwind info as usual, or it can tailcall them (that is
what GCC usually doesn't do) and then it is like any other tail call, you
can't see the original caller, but you can see a caller of that caller (or
perhaps with a bunch of other frames missing), but still something
unwindable.
Jakub
