<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 16, 2021, 6:57 PM Kinsey Moore <<a href="mailto:kinsey.moore@oarcorp.com">kinsey.moore@oarcorp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Yes. Adacore is involved and we are trying to provide what they expect now.</div><div dir="auto"><br></div><div dir="auto">--joel</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>
<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>