Hi Maciej: Thanks for your explanation, I am OK with this change for the RISC-V port now, but I think I don't have permission to approve this patch since it's more than RISC-V port specific, maybe you need approval from Richard Biener.
On Wed, Aug 26, 2020 at 12:33 AM Maciej W. Rozycki via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > 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
