[PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS
Fri Aug 28 15:47:22 GMT 2020
On Wed, Aug 26, 2020 at 12:08 PM Richard Biener via Gcc-patches
> On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki <email@example.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.
> > Maciej
More information about the Gcc-patches