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

[Joel Sherrill]

On Sun, Apr 18, 2021, 5:13 PM Chris Johns <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> 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. If the user
wanted more detail, they would like have to poke directly before it becomes
a signal.

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

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

>
> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210418/99929eb3/attachment-0001.html>