From: Jakub Jelinek <jakub@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Nathan Sidwell <nathan@acm.org>, GCC <gcc@gcc.gnu.org>,
GNU C Library <libc-alpha@sourceware.org>,
Binutils <binutils@sourceware.org>,
gnu-gabi@sourceware.org
Subject: Re: Invalid program counters and unwinding
Date: Mon, 01 Jan 2018 00:00:00 -0000 [thread overview]
Message-ID: <20180626114508.GQ7166@tucnak> (raw)
In-Reply-To: <d1d58d83-cf2a-c91d-385b-07afbed26593@redhat.com>
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
prev parent reply other threads:[~2018-06-26 11:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-01 0:00 Florian Weimer
2018-01-01 0:00 ` Jeff Law
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Jeff Law
2018-01-01 0:00 ` Michael Matz
2018-01-01 0:00 ` Jakub Jelinek
2018-01-01 0:00 ` Michael Matz
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Nathan Sidwell
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Jakub Jelinek
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Nathan Sidwell
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Nathan Sidwell
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Nathan Sidwell
2018-01-01 0:00 ` Jakub Jelinek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180626114508.GQ7166@tucnak \
--to=jakub@redhat.com \
--cc=binutils@sourceware.org \
--cc=fweimer@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=gnu-gabi@sourceware.org \
--cc=libc-alpha@sourceware.org \
--cc=nathan@acm.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).