On Fri, Aug 28, 2020 at 04:40:48PM +0100, Maciej W. Rozycki wrote:
> 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
-fasynchronous-unwind-tables is solely about whether one can unwind through
the code, but not necessarily that EH will work. If it is not turned on,
non-call exceptions will certainly not work properly, because unwind info
if present at all will only be correct on call insns and not guaranteed on
anything else.
-fexceptions enables EH handling in whatever function it is turned on,
entries in .gcc_except_table as well as a personality routine will be added
for it, calls from it which can throw (including special calls like throw)
will be marked there and cause EH regions, similarly EH pads will be added
for anything where an exception needs to be caught or where a cleanup needs
to be run before continuing with the unwinding (e.g. destructors or cleanup
attribute). But still, it only expects that call can throw, not arbitrary
instructions, so those won't be covered necessarily in EH regions, in the IL
there won't be EH edges etc.
-fnon-call-exceptions is like -fexceptions, except in addition to calls
(that may throw) it considers also possibly trapping instructions as
something that can throw. So way too many more EH edges, EH regions etc.
Now, I'd say if for some trapping instruction in a function we want to throw
an exception from a signal handler, surely the signal handler needs to be
built with -fexceptions, but as long as the function that contains the
trapping instruction doesn't really need to catch the exception (including
running a cleanup in it and continuing with the exception), i.e. when the
exception is thrown from the signal handler and caught in some caller of the
function with the trapping instruction, I'd say all that needs to be done
is the function with the trapping instruction be compiled with
-fasynchronous-unwind-tables and the callers of it that are still not meant
to catch it should be compiled with -funwind-tables (or
-fasynchronous-unwind-tables) and only the function that should catch it or
run cleanups should be compiled with -fexceptions (no need for
-fnon-call-exceptions in that case, but of course not disallowed).
This is for DWARF EH, I have no idea how ARM, or IA64 EH works, so it might
be different for those.
So, if Ada has testsuite coverage for EH throwing on division or modulo by
zero and your patch doesn't break Ada on at least some common DWARF using target
and ARM (let's ignore IA64), I'd say replacing
LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions -fnon-call-exceptions
with
LIB2_DIVMOD_EXCEPTION_FLAGS := -fasynchronous-unwind-tables
looks reasonable to me.
Jakub
