On 18/4/21 8:40 am, Joel Sherrill wrote: > > > On Sat, Apr 17, 2021, 4:27 PM Gedare Bloom <ged...@rtems.org > <mailto:ged...@rtems.org>> wrote: > > On Sat, Apr 17, 2021 at 8:10 AM Joel Sherrill <j...@rtems.org > <mailto:j...@rtems.org>> wrote: > > > > > > > > On Sat, Apr 17, 2021, 8:25 AM Gedare Bloom <ged...@rtems.org > <mailto:ged...@rtems.org>> wrote: > >> > >> On Fri, Apr 16, 2021 at 6:59 PM Joel Sherrill <j...@rtems.org > <mailto:j...@rtems.org>> wrote: > >> > > >> > > >> > > >> > On Fri, Apr 16, 2021, 6:57 PM Kinsey Moore <kinsey.mo...@oarcorp.com > <mailto: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 <mailto: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? > > > The SPARC is the only other one with any existing support like this. It will > be > updated but the others will just wait for someone to need it to be functional. > Likely just a stub if that's required to link.
Is networking a requirement now or into the future? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel