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? How would this type of signal support be implemented on the 32bit ARM arch and maintain libdebugger support? How would libdebugger be integrated on the aarch64 with this change? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
