On Wed, 26 Aug 2020, Jakub Jelinek wrote:
> On Wed, Aug 26, 2020 at 01:08:00PM +0200, Richard Biener via Gcc-patches
> wrote:
> > You only need -fexceptions for that, then you can throw; from a signal
> > handler
> > for example. If you want to be able to catch the exception somewhere up
> > the call chain all intermediate code needs to be compiled so that unwinding
> > from asynchronous events is possible - -fasynchronous-unwind-tables.
> >
> > So -fasynchronous-unwind-tables is about unwinding. -f[non-call]-exceptions
> > is about throw/catch. Clearly libgcc does neither throw nor catch but with
> > async events we might need to unwind from inside it.
Thank you for the clarification.
As far as `-fexceptions' and `-fasynchronous-unwind-tables' are concerned
it aligns with my understanding, i.e. in this specific scenario we need
`-fasynchronous-unwind-tables' for libcalls (all of them) so that an
exception thrown from a signal handler can unwind through our code, and it
is the signal handler that needs `-fexceptions' to be able to throw an
exception, and then another piece of code upwards the call chain also
needs `-fexceptions' to catch it.
I'm still unclear as to `-fnon-call-exceptions' as what you write,
combined with documentation for said option seems to imply that it causes
a signal handler to be installed for SIGBUS/SIGSEGV/SIGFPE, however I seem
unable to locate such code except for the Ada frontend.
The option does cause certain instruction classes, as per `may_trap_p_1',
to be annotated for exception handling and prevent them from being
optimised away, but it is not clear to me what the difference is between
the case where a piece of code has been built with `-fnon-call-exceptions'
and `-fasynchronous-unwind-tables', and an instruction within (that hasn't
been optimised away) traps into an exception handler that throws an
exception. I.e. what the extra annotation is used for (obviously being
optimised away or not is a significat difference).
IIUC in both cases the exact causing instruction can be identified,
especially as I note that internally `-fnon-call-exceptions' implies
`-fasynchronous-unwind-tables':
if (flag_non_call_exceptions)
flag_asynchronous_unwind_tables = 1;
(which I suspect might be worth documenting).
> In C code -f{,non-call-}exceptions is also about whether cleanup attribute
> will work or not. But I think in libgcc we don't really use it, especially
> not in the division/modulo code, not even indirectly from libc headers like
> pthread_cleanup_* macros.
Thank you for your observation, I didn't know of the cleanup attribute
before.
So what shall we do about my patch?
Maciej
