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

[Gedare Bloom]

On Fri, Apr 23, 2021 at 8:28 AM Kinsey Moore  wrote:
>
> On 4/20/2021 01:44, Chris Johns wrote:
> > On 20/4/21 4:38 pm, Sebastian Huber wrote:
> >> On 20/04/2021 08:30, Chris Johns wrote:
> >>> On 20/4/21 3:54 pm, Sebastian Huber wrote:
>  On 20/04/2021 07:30, Chris Johns wrote:
> 
> > 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.
>  The fatal error extensions execute in a user controllable order. You can 
>  for
>  example register a libdebugger handler which deals with break point 
>  exceptions
>  before the signal mapping handler is called.
> 
>  Synchronous exceptions should end up in an RTEMS_FATAL_SOURCE_EXCEPTION 
>  fatal
>  error. The fatal code is a pointer to rtems_exception_frame
>  (CPU_Exception_frame). In this data structure should be the complete 
>  state of
>  the interrupted context (which could be also an interrupt handler). If 
>  you want
>  to resume execution of the interrupted context, then we need an API for 
>  this
>  (setters/getters and some sort of a longjmp()).
> >>> I do not think the fatal error handler support is suitable for a 
> >>> debugger, the
> >>> frame maybe on the wrong stack. It was more complicated to implement than 
> >>> this
> >>> and the reality of what is needed on the ARM required lots more. The 
> >>> fatal error
> >>> handler handles fatal errors however surviving a data abort and then 
> >>> continuing
> >>> in the correct CPU context/space and stack is much harder to do 
> >>>
> >>> https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n1454
> >>>
> >>> That code has to work with all data and states saved.
> >> Yes, this code is the "some sort of a longjump()". The code mentioned above
> >> doesn't seem to be necessarily libdebugger-specific.
> > Ah OK we agree :). I would love to see that happen.
> >
> > The fatal error handler API would then be built on an exception management 
> > API.
> > I personally believe this is a key piece of functionality RTEMS would 
> > benefit
> > from. It would make adding signal support easy.
>
>
> My initial thoughts on an exception management API (EMAPI):
>
> additional CPU port requirements for EMAPI support:
>  provide functions which operate on CPU Exception Frame (CEF)
>  get address of exception
>  get exception class (these will be as granular as possible
> while still being arch-agnostic)
>  set address to resume execution as instruction after exception
>  set address to resume execution (arbitrary)
>
>  upon exception, creates CEF on thread stack and calls into EMAPI
>  upon return from EMAPI, restores CEF and returns to normal execution
>
> EMAPI:
>  No architecture-specific information is directly exposed
>  CEF is provided as a handle on which to operate
>  architecture-specific details can be pulled from CEF if necessary
>
>
>  handler gets CEF as only argument
>  handler return value determines whether it took final actions based
> on the CEF
>
>  handler list is ordered based on priority, but not otherwise keyed
>  a handler that takes a final action prevents execution of
> further handlers
>
>  lowest priority handler is always present (frame dump and fatal
> extensions run here)
>

I think this belongs in a new thread for discussion and easier
search/reference in future. This smells important :)

>
> Kinsey
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Kinsey Moore]

On 4/20/2021 01:44, Chris Johns wrote:

On 20/4/21 4:38 pm, Sebastian Huber wrote:

On 20/04/2021 08:30, Chris Johns wrote:

On 20/4/21 3:54 pm, Sebastian Huber wrote:

On 20/04/2021 07:30, Chris Johns wrote:


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.

The fatal error extensions execute in a user controllable order. You can for
example register a libdebugger handler which deals with break point exceptions
before the signal mapping handler is called.

Synchronous exceptions should end up in an RTEMS_FATAL_SOURCE_EXCEPTION fatal
error. The fatal code is a pointer to rtems_exception_frame
(CPU_Exception_frame). In this data structure should be the complete state of
the interrupted context (which could be also an interrupt handler). If you want
to resume execution of the interrupted context, then we need an API for this
(setters/getters and some sort of a longjmp()).

I do not think the fatal error handler support is suitable for a debugger, the
frame maybe on the wrong stack. It was more complicated to implement than this
and the reality of what is needed on the ARM required lots more. The fatal error
handler handles fatal errors however surviving a data abort and then continuing
in the correct CPU context/space and stack is much harder to do 

https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n1454

That code has to work with all data and states saved.

Yes, this code is the "some sort of a longjump()". The code mentioned above
doesn't seem to be necessarily libdebugger-specific.

Ah OK we agree :). I would love to see that happen.

The fatal error handler API would then be built on an exception management API.
I personally believe this is a key piece of functionality RTEMS would benefit
from. It would make adding signal support easy.



My initial thoughts on an exception management API (EMAPI):

additional CPU port requirements for EMAPI support:
    provide functions which operate on CPU Exception Frame (CEF)
        get address of exception
        get exception class (these will be as granular as possible 
while still being arch-agnostic)

        set address to resume execution as instruction after exception
        set address to resume execution (arbitrary)

    upon exception, creates CEF on thread stack and calls into EMAPI
    upon return from EMAPI, restores CEF and returns to normal execution

EMAPI:
    No architecture-specific information is directly exposed
        CEF is provided as a handle on which to operate
        architecture-specific details can be pulled from CEF if necessary


    handler gets CEF as only argument
    handler return value determines whether it took final actions based 
on the CEF


    handler list is ordered based on priority, but not otherwise keyed
        a handler that takes a final action prevents execution of 
further handlers


    lowest priority handler is always present (frame dump and fatal 
extensions run here)



Kinsey

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Chris Johns]

On 20/4/21 4:38 pm, Sebastian Huber wrote:
> 
> On 20/04/2021 08:30, Chris Johns wrote:
>> On 20/4/21 3:54 pm, Sebastian Huber wrote:
>>> On 20/04/2021 07:30, Chris Johns wrote:
>>>
 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.
>>> The fatal error extensions execute in a user controllable order. You can for
>>> example register a libdebugger handler which deals with break point 
>>> exceptions
>>> before the signal mapping handler is called.
>>>
>>> Synchronous exceptions should end up in an RTEMS_FATAL_SOURCE_EXCEPTION 
>>> fatal
>>> error. The fatal code is a pointer to rtems_exception_frame
>>> (CPU_Exception_frame). In this data structure should be the complete state 
>>> of
>>> the interrupted context (which could be also an interrupt handler). If you 
>>> want
>>> to resume execution of the interrupted context, then we need an API for this
>>> (setters/getters and some sort of a longjmp()).
>> I do not think the fatal error handler support is suitable for a debugger, 
>> the
>> frame maybe on the wrong stack. It was more complicated to implement than 
>> this
>> and the reality of what is needed on the ARM required lots more. The fatal 
>> error
>> handler handles fatal errors however surviving a data abort and then 
>> continuing
>> in the correct CPU context/space and stack is much harder to do 
>>
>> https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n1454
>>
>> That code has to work with all data and states saved.
> Yes, this code is the "some sort of a longjump()". The code mentioned above
> doesn't seem to be necessarily libdebugger-specific.

Ah OK we agree :). I would love to see that happen.

The fatal error handler API would then be built on an exception management API.
I personally believe this is a key piece of functionality RTEMS would benefit
from. It would make adding signal support easy.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Sebastian Huber]

On 20/04/2021 08:30, Chris Johns wrote:

On 20/4/21 3:54 pm, Sebastian Huber wrote:

On 20/04/2021 07:30, Chris Johns wrote:


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.

The fatal error extensions execute in a user controllable order. You can for
example register a libdebugger handler which deals with break point exceptions
before the signal mapping handler is called.

Synchronous exceptions should end up in an RTEMS_FATAL_SOURCE_EXCEPTION fatal
error. The fatal code is a pointer to rtems_exception_frame
(CPU_Exception_frame). In this data structure should be the complete state of
the interrupted context (which could be also an interrupt handler). If you want
to resume execution of the interrupted context, then we need an API for this
(setters/getters and some sort of a longjmp()).

I do not think the fatal error handler support is suitable for a debugger, the
frame maybe on the wrong stack. It was more complicated to implement than this
and the reality of what is needed on the ARM required lots more. The fatal error
handler handles fatal errors however surviving a data abort and then continuing
in the correct CPU context/space and stack is much harder to do 

https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n1454

That code has to work with all data and states saved.
Yes, this code is the "some sort of a longjump()". The code mentioned 
above doesn't seem to be necessarily libdebugger-specific.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Chris Johns]

On 20/4/21 3:54 pm, Sebastian Huber wrote:
> On 20/04/2021 07:30, Chris Johns wrote:
> 
>> 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.
> 
> The fatal error extensions execute in a user controllable order. You can for
> example register a libdebugger handler which deals with break point exceptions
> before the signal mapping handler is called.
> 
> Synchronous exceptions should end up in an RTEMS_FATAL_SOURCE_EXCEPTION fatal
> error. The fatal code is a pointer to rtems_exception_frame
> (CPU_Exception_frame). In this data structure should be the complete state of
> the interrupted context (which could be also an interrupt handler). If you 
> want
> to resume execution of the interrupted context, then we need an API for this
> (setters/getters and some sort of a longjmp()).

I do not think the fatal error handler support is suitable for a debugger, the
frame maybe on the wrong stack. It was more complicated to implement than this
and the reality of what is needed on the ARM required lots more. The fatal error
handler handles fatal errors however surviving a data abort and then continuing
in the correct CPU context/space and stack is much harder to do 

https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n1454

That code has to work with all data and states saved.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Sebastian Huber]

On 20/04/2021 07:30, Chris Johns wrote:


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.


The fatal error extensions execute in a user controllable order. You can 
for example register a libdebugger handler which deals with break point 
exceptions before the signal mapping handler is called.


Synchronous exceptions should end up in an RTEMS_FATAL_SOURCE_EXCEPTION 
fatal error. The fatal code is a pointer to rtems_exception_frame 
(CPU_Exception_frame). In this data structure should be the complete 
state of the interrupted context (which could be also an interrupt 
handler). If you want to resume execution of the interrupted context, 
then we need an API for this (setters/getters and some sort of a longjmp()).


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [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 >> > 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
>>>  >> >>  > 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 

Re: [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 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
 >> 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.



 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 

Re: [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  > 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
> >>  > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Joel Sherrill]

On Sun, Apr 18, 2021, 5:13 PM Chris Johns  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
> >>  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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Chris Johns]

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

How would this type of signal support be implemented on the 32bit ARM arch and
maintain libdebugger support?

How would libdebugger be integrated on the aarch64 with this change?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Kinsey Moore]

On 4/16/2021 08:48, Gedare Bloom wrote:

On Fri, Apr 16, 2021 at 1:19 AM Sebastian Huber
 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.



Kinsey

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Gedare Bloom]

On Fri, Apr 16, 2021 at 1:19 AM Sebastian Huber
 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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Sebastian Huber]

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.


On 14/04/2021 17:46, Kinsey Moore wrote:

This adds a confdef option allowing an application to request mapping
machine exceptions to POSIX signals. This is required for some languages
such as Ada.


[...]


diff --git a/cpukit/include/rtems/exceptions.h 
b/cpukit/include/rtems/exceptions.h
new file mode 100644
index 00..5e43827d11
--- /dev/null
+++ b/cpukit/include/rtems/exceptions.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @brief Exception mapping
+ *
+ * This file describes the hooks necessary for mapping machine exceptions to
+ * POSIX signals.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Research
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTEMS_EXCEPTIONS_H
+#define _RTEMS_EXCEPTIONS_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @brief Configures the desired mapping for machine exceptions to POSIX
+ * signals.
+ *
+ * See CONFIGURE_APPLICATION_NEEDS_EXCEPTION_TO_SIGNAL_MAPPING documentation 
in the
+ * "RTEMS Classic API Guide".
+ */
+void _Exception_initialize_signal_mapping( void );
+
+#ifdef __cplusplus
+}
+#endif
The #include  location should be used for header files which 
provide API elements. API elements should be in the rtems_* namespace.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel