<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 17, 2021, 8:25 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Apr 16, 2021 at 6:59 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a>> wrote:<br>
><br>
><br>
><br>
> On Fri, Apr 16, 2021, 6:57 PM Kinsey Moore <<a href="mailto:kinsey.moore@oarcorp.com" target="_blank" rel="noreferrer">kinsey.moore@oarcorp.com</a>> wrote:<br>
>><br>
>> On 4/16/2021 09:00, Gedare Bloom wrote:<br>
>> > On Wed, Apr 14, 2021 at 9:47 AM Kinsey Moore <<a href="mailto:kinsey.moore@oarcorp.com" target="_blank" rel="noreferrer">kinsey.moore@oarcorp.com</a>> wrote:<br>
>> >> This adds support for mapping AArch64 machine exceptions to POSIX<br>
>> >> signals as necessary for running Ada applications.<br>
>> >> ---<br>
>> >> <snip><br>
>> >> +  kill(getpid(), signal);<br>
>> > Not just map it, but actually send it. I'm not convinced this design<br>
>> > is the right way to deal with this problem. In addition to Sebastian's<br>
>> > suggestion on using a fatal error handler, you may consider a user<br>
>> > task to handle this. I think that kill() can have quite a large stack<br>
>> > consumption? It is a very complex call to include in the 'normal'<br>
>> > exception handling path with a giant switch to turn it on/off.<br>
>> ><br>
>> > If you have some analysis or justification for this design, I'd be<br>
>> > glad to consider it. However, at a glance, it adds kill() to the<br>
>> > WCET/latency of all synchronous exception handling when this option is<br>
>> > enabled. Something about this feels off.<br>
>><br>
>> My only justification is that it is modeled on similar code in the SPARC<br>
>> BSPs (bsps/sparc/shared/gnatcommon.c) to handle these kinds of mappings<br>
>> for Ada. I assumed since it was already in place that it was the<br>
>> preferred method to accomplish this goal.<br>
><br>
Shimming this stuff into the score CPU port with the configuration<br>
option is suddenly imposing a huge burden across the rest of the<br>
ports.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Originally on the SPARC, this was an optional registration. </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
I need more convincing. I'm not saying this is necessarily wrong, but<br>
I think it is breaking multiple kind of design rules inside of the<br>
score. I encourage you to explain and justify this design against<br>
alternatives, such as using the fatal extension handlers, implementing<br>
it in the BSP layer, or registering new exception handlers at the<br>
application layer.<br>
<br>
What happens in a classic task when an exception raises and there's no<br>
signal handler?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What will happen if someone wants to mix multiple language runtimes in<br>
their application?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Whichever runtime registers last wins. Unfortunately, you only have one thread registered.</div><div dir="auto"><br></div><div dir="auto">We can ask Adacore these questions. Signals is how their runtime does work on other platforms. And those have the same concerns.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 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.<br>
><br>
That makes sense at least. That is an abstract design though.<br>
<br>
> Yes. Adacore is involved and we are trying to provide what they expect now.<br>
><br>
> --joel<br>
><br>
>><br>
>><br>
>> Kinsey<br>
>><br>
>><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>