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

Joel Sherrill joel at rtems.org
Sat Apr 17 00:58:45 UTC 2021


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.
>

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.

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.

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/20210416/be17a5cd/attachment-0001.html>


More information about the devel mailing list