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

[Kinsey Moore]

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.
>
>>      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..

>
>>      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.


Kinsey