On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki <ma...@wdc.com> 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.
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. Now I don't know about the arm situation but if arm cannot do async unwinding then even -fexceptions won't help it here - libgcc still does not throw. Richard. > > Maciej
