On Fri, Aug 28, 2020 at 5:47 PM Ramana Radhakrishnan <ramana....@googlemail.com> wrote: > > 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.
And surely building libgcc with -fexceptions does not change that either. Richard. > regards > Ramana > > > > > Richard. > > > > > > > > Maciej
