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

[Gedare Bloom]

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?

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