On 20/4/21 5:02 am, Kinsey Moore wrote: > On 4/18/2021 20:18, Chris Johns wrote: >> 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. > I think Joel meant optional the same way libdebugger is optional. This change > operates the same way on AArch64 that libdebugger operates on ARMv7. >> >>> 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. > It's likely to be just as painful as ARMv7. I spent part of the morning > reviewing the relevant libdebugger code and both hook directly into the vector > table. As things stand, libdebugger and this code can not coexist on ARMv7 or > AArch64.
I suppose the debugger needs to be able to capture the exceptions over this code. I think that works? >> >>> 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? > > The current implementation of both libdebugger on ARMv7 and this exception to > signal translator on AArch64 are very similar in how they operate. libdebugger > on ARMv7 hooks every exception type at the vector table while this translator > hooks the common/unified exception vector for AArch64. There isn't currently a > way they could even partially share the exceptions as there isn't a mechanism > available to register hooks to them individually. > > Some form of sharing could be possible on SPARC since both exceptions and IRQs > are just different ranges of traps (all of which have handler hooks), but with > possibly reduced functionality on the libdebugger side since some of the > exceptions libdebugger typically catches would instead get translated and > pushed > into whichever runtime was operating, be it Ada, C++, Fortran, etc.. We need a way for libdebugger or any other piece of software to capture and cascade the call. If this can be done on aarch64 then I am happy. >>> 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? > They are currently exclusive as a block as implemented on ARMv7 and AArch64. > For > these two to coexist, there would need to be a mechanism to attach handlers to > various machine-specific exceptions. They could also be shoehorned into the > interrupt handler table at an offset to get behavior more similar to SPARC. >> >> Are the exceptions chained? > > Neither libdebugger nor signal translation allows for exception chaining. Are you sure? https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n1366 It does this for the ARM and i386. For example if libdebugger detects the exception is in itself that exception is cascaded. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
