On 19/4/21 9:23 am, Joel Sherrill wrote: > > > On Sun, Apr 18, 2021, 5:13 PM Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org>> wrote: > > On 17/4/21 10:00 am, Kinsey Moore wrote: > > On 4/16/2021 08:48, Gedare Bloom wrote: > >> On Fri, Apr 16, 2021 at 1:19 AM Sebastian Huber > >> <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > >>> Hello Kinsey, > >>> > >>> why don't you use a fatal error extension for this? You can save all > the > >>> processor state to a structure and use it to jump to previous or next > >>> instruction it if needed in a custom fatal error handler which deals > >>> with RTEMS_FATAL_EXCEPTION. I think libdebugger uses this approach. > >>> > >> +1 > >> > >> This is otherwise a major overhaul/addition to the CPU port > >> requirements. I'd lean in favor of adding any CPU_* API that is > >> necessary to support vectoring from an exception to a signal. I don't > >> think we can make this kind of intrusive modification to basic > >> interrupt handling capabilities across all ports easily. Some of that > >> code is old and very stable. > > > > I avoided going that direction to maintain the interrupt stack since an > > exception return from within those handlers would necessarily leave the > CPU > > state as well as intervening functions on the stack along with a minor > amount of > > data on the thread stack. In addition, thread dispatch needs to occur > and all > > exception handling for AArch64 (as modeled after ARM) is currently > considered > > final with no way to reasonably return to execution. > > > > Not every platform will need this kind of intrusive change. Any > platform that > > handles exceptions in a manner similar to IRQs can deal with this > exception > > mapping far more trivially. ARM and AArch64 don't have that luxury, but > SPARC > > does and I assume others do as well. > > How would a user in an application debug a data abort error if all they > get is a > signal? > > > This is optional and just the way certain Ada exceptions work.
Optional means what? What about other optional pieces? Does the change have a wider use case than Ada? I think it may which is good. As a result I feel we need to consider other users of exceptions and how they may interact with this change. > If the user > wanted more detail, they would like have to poke directly before it becomes a > signal. I would connect a debugger and then expect to have the pc left at the faulting instruction. At a technical level this means the faulting exception frame needs to be handled and not compacted down to a single signal. On a 32 bit ARM it is a very difficult piece of code and I would be pleasantly surprised if you did not need this on an aarch64. > How would this type of signal support be implemented on the 32bit ARM > arch and > maintain libdebugger support? > > Is there a technical limitation I don't know about? On the SPARC, it > recognizes > that only certain faults can be mapped. Not specifically, I am just wondering how each part of our code integrates. Does adding aarch64 to libdebugger need to work with these changes so the signal exception confdef option is still works? And then the other way around does adding exception signal support to the 32 bit ARM have to deal with libdebugger as it exists? Who is paying the tax and what does it look like? > How would libdebugger be integrated on the aarch64 with this change? > > Again what's the limitation? You appear to there's something about the > architecture that would cause a clash. Are the exceptions a shared resource or exclusive? If shared, how? If exclusive does this mean an aarch64 libdebugger back end does not need to deal with the same exceptions and this change? Are the exceptions chained? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
