On Fri, Apr 16, 2021 at 6:59 PM Joel Sherrill <j...@rtems.org> wrote: > > > > On Fri, Apr 16, 2021, 6:57 PM Kinsey Moore <kinsey.mo...@oarcorp.com> wrote: >> >> On 4/16/2021 09:00, Gedare Bloom wrote: >> > On Wed, Apr 14, 2021 at 9:47 AM Kinsey Moore <kinsey.mo...@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.
> > 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? What will happen if someone wants to mix multiple language runtimes in their application? > 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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel