On Wed, Aug 26, 2020 at 12:08 PM Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > 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.
On Arm as in the AArch32 port, async unwinding will not work as those can't be expressed in the EH format tables. regards Ramana > > Richard. > > > > > Maciej
