On Sat, Apr 17, 2021 at 8:10 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Sat, Apr 17, 2021, 8:25 AM Gedare Bloom <ged...@rtems.org> wrote: >> >> 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. > > > 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@rtems.org >> >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
