[PATCH v1 1/3] cpukit: Add signal mapping support

[Chris Johns]

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 <chrisj at rtems.org
>>> <mailto:chrisj at 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.huber at embedded-brains.de
>>>      <mailto:sebastian.huber at 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