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

[Chris Johns]

On 18/4/21 8:40 am, Joel Sherrill wrote:
> 
> 
> On Sat, Apr 17, 2021, 4:27 PM Gedare Bloom <gedare at rtems.org
> <mailto:gedare at rtems.org>> wrote:
> 
>     On Sat, Apr 17, 2021 at 8:10 AM Joel Sherrill <joel at rtems.org
>     <mailto:joel at rtems.org>> wrote:
>     >
>     >
>     >
>     > On Sat, Apr 17, 2021, 8:25 AM Gedare Bloom <gedare at rtems.org
>     <mailto:gedare at rtems.org>> wrote:
>     >>
>     >> On Fri, Apr 16, 2021 at 6:59 PM Joel Sherrill <joel at rtems.org
>     <mailto:joel at rtems.org>> wrote:
>     >> >
>     >> >
>     >> >
>     >> > On Fri, Apr 16, 2021, 6:57 PM Kinsey Moore <kinsey.moore at oarcorp.com
>     <mailto: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 <mailto: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.

Is networking a requirement now or into the future?

Chris