On Sun, Apr 18, 2021, 5:13 PM Chris Johns <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> 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. If the user wanted more detail, they would like have to poke directly before it becomes a signal. > > 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. > > 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. > > Chris > _______________________________________________ > 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
