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

[Chris Johns]

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.

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

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

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

Are the exceptions chained?

Chris