[PATCH v1 2/3] aarch64: Add support for mapping exceptions

[Joel Sherrill]

On Sat, Apr 17, 2021, 4:27 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Sat, Apr 17, 2021 at 8:10 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Sat, Apr 17, 2021, 8:25 AM Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> On Fri, Apr 16, 2021 at 6:59 PM Joel Sherrill <joel at rtems.org> wrote:
> >> >
> >> >
> >> >
> >> > On Fri, Apr 16, 2021, 6:57 PM Kinsey Moore <kinsey.moore at oarcorp.com>
> wrote:
> >> >>
> >> >> On 4/16/2021 09:00, Gedare Bloom wrote:
> >> >> > On Wed, Apr 14, 2021 at 9:47 AM Kinsey Moore <
> kinsey.moore at oarcorp.com> wrote:
> >> >> >> This adds support for mapping AArch64 machine exceptions to POSIX
> >> >> >> signals as necessary for running Ada applications.
> >> >> >> ---
> >> >> >> <snip>
> >> >> >> +  kill(getpid(), signal);
> >> >> > Not just map it, but actually send it. I'm not convinced this
> design
> >> >> > is the right way to deal with this problem. In addition to
> Sebastian's
> >> >> > suggestion on using a fatal error handler, you may consider a user
> >> >> > task to handle this. I think that kill() can have quite a large
> stack
> >> >> > consumption? It is a very complex call to include in the 'normal'
> >> >> > exception handling path with a giant switch to turn it on/off.
> >> >> >
> >> >> > If you have some analysis or justification for this design, I'd be
> >> >> > glad to consider it. However, at a glance, it adds kill() to the
> >> >> > WCET/latency of all synchronous exception handling when this
> option is
> >> >> > enabled. Something about this feels off.
> >> >>
> >> >> My only justification is that it is modeled on similar code in the
> SPARC
> >> >> BSPs (bsps/sparc/shared/gnatcommon.c) to handle these kinds of
> mappings
> >> >> for Ada. I assumed since it was already in place that it was the
> >> >> preferred method to accomplish this goal.
> >> >
> >> Shimming this stuff into the score CPU port with the configuration
> >> option is suddenly imposing a huge burden across the rest of the
> >> ports.
> >
> >
> > Originally on the SPARC, this was an optional registration.
> >>
> >>
> >> >
> >> > The Ada runtime maps certain CPU exceptions to Ada exceptions via
> signals. We haven't checked C++ yet but it may be similar for at least
> SIGFPE.
> >> >
> >> > We want to standardise this  across the few BSPs that have it and add
> a configuration option if the user wants this signal mapping expected by at
> least Ada.
> >> >
> >> I need more convincing. I'm not saying this is necessarily wrong, but
> >> I think it is breaking multiple kind of design rules inside of the
> >> score. I encourage you to explain and justify this design against
> >> alternatives, such as using the fatal extension handlers, implementing
> >> it in the BSP layer, or registering new exception handlers at the
> >> application layer.
> >>
> >> What happens in a classic task when an exception raises and there's no
> >> signal handler?
> >
> >
> > Classic API tasks have all signals masked. I think that includes all
> ones which are normally not maskable. So it should be we be delivered.
> >
> >>
> >> What will happen if someone wants to mix multiple language runtimes in
> >> their application?
> >
> >
> > Whichever runtime registers last wins. Unfortunately, you only have one
> thread registered.
> >
> > We can ask Adacore these questions. Signals is how their runtime does
> work on other platforms. And those have the same concerns.
> >
> Thanks. What's your plan for the remaining architectures?
>

The SPARC is the only other one with any existing support like this. It
will be updated but the others will just wait for someone to need it to be
functional. Likely just a stub if that's required to link.


> >
> >>
> >> > There are initial plans to map device interrupts through interrupt
> threads to something more real time. Because Ada interrupts for real
> purposes need a better mechanism than signals. But we need to work out what
> Adacore needs.
> >> >
> >> That makes sense at least. That is an abstract design though.
> >>
> >> > Yes. Adacore is involved and we are trying to provide what they
> expect now.
> >> >
> >> > --joel
> >> >
> >> >>
> >> >>
> >> >> Kinsey
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> devel mailing list
> >> >> devel at rtems.org
> >> >> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210417/1e748dad/attachment-0001.html>