[PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Richard Biener]

On Fri, Aug 28, 2020 at 5:47 PM Ramana Radhakrishnan
<ramana.gcc@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 <macro@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