[PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS
Maciej W. Rozycki
Tue Aug 25 16:32:46 GMT 2020
> I just found the mail thread about div mod with -fnon-call-exceptions,
> I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS unchanged
> should be the best way to go.
> Non-call exceptions and libcalls
> Non-call exceptions and libcalls Part 2
Thank you for your input. I believe I had a look at these commits before
I posted my original proposal. Please note however that they both predate
the addition of `-fasynchronous-unwind-tables', so clearly the option
could not have been considered at the time the changes were accepted into
Please note that, as observed by Andreas and Richard here:
<https://gcc.gnu.org/pipermail/gcc/2020-July/233122.html> in no case we
want to have full exception handling here, so we clearly need no
`-fexceptions'; this libcall code won't itself ever call `throw'.
Now it might be a bit unclear from documentation as to whether we want
`-fnon-call-exceptions' or `-fasynchronous-unwind-tables', as it says that
the former option makes GCC:
" Generate code that allows trapping instructions to throw
exceptions. Note that this requires platform-specific runtime
support that does not exist everywhere. Moreover, it only allows
_trapping_ instructions to throw exceptions, i.e. memory references
or floating-point instructions. It does not allow exceptions to be
thrown from arbitrary signal handlers such as 'SIGALRM'."
Note the observation that arbitrary signal handlers (invoked at more inner
a frame level, and necessarily built with `-fexceptions') are still not
allowed to throw exceptions. For that, as far as I understand it, you
actually need `-fasynchronous-unwind-tables', which makes GCC:
" Generate unwind table in DWARF format, if supported by target
machine. The table is exact at each instruction boundary, so it
can be used for stack unwinding from asynchronous events (such as
debugger or garbage collector)."
and therefore allows arbitrary signal handlers to throw exceptions,
effectively making the option a superset of `-fexceptions'. As libcall
code can generally be implicitly invoked everywhere, we want people not to
be restrained by it and let a exception thrown by e.g. a user-supplied
SIGALRM handler propagate through the relevant libcall's stack frame,
rather than just those exceptions the libcall itself might indirectly
Maybe I am missing something here, especially as `-fexceptions' mentions
code generation, while `-fasynchronous-unwind-tables' only refers to
unwind table generation, but then what would be the option to allow
exceptions to be thrown from arbitrary signal handlers rather than those
for memory references or floating-point instructions (where by a special
provision integer division falls as well)?
My understanding has been it is `-fasynchronous-unwind-tables', but I'll
be gladly straightened out otherwise. If I am indeed right, then perhaps
the documentation could be clarified and expanded a bit.
Barring evidence to the contrary I maintain the change I have proposed is
correct, and not only removes the RISC-V `ld.so' build issue, but it fixes
the handling of asynchronous events arriving in the middle of the relevant
libcalls for all platforms as well.
Please let me know if you have any further questions, comments or
More information about the Gcc-patches