Hi Kito, > 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 > https://gcc.gnu.org/legacy-ml/gcc/2001-06/msg01108.html > > Non-call exceptions and libcalls Part 2 > https://gcc.gnu.org/legacy-ml/gcc/2001-07/msg00402.html
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 GCC. 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 cause. 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 concerns. Maciej