[PATCH 0/5] Preliminary Exception Manager Work

[Kinsey Moore]

On 8/27/2021 19:04, Chris Johns wrote:
> On 24/8/21 10:34 pm, Kinsey Moore wrote:
>> On 8/23/2021 21:41, Chris Johns wrote:
>>> On 24/8/21 9:50 am, Kinsey Moore wrote:
>>>> This patch set contains the result of the Exception Manager work I
>>>> proposed a while back to manage handling of machine exceptions along
>>>> with a general feature for mapping exceptions to POSIX signals without
>>>> delving into the CPU Port-specific details. This is a pretty basic
>>>> initial implementation, but it can easily be expanded with mutators for
>>>> the CPU_Exception_frame for additional capabilities. Also included is a
>>>> test that demonstrates usage of the Exception Manager and exception to
>>>> signal mapping functionality.
>>> Could you please provide a link to the previous discussion?
>> Most of the discussion occurred here:
>>
>> https://lists.rtems.org/pipermail/devel/2021-April/066597.html
>>
>> I sent out my consolidated thoughts here:
>>
>> https://lists.rtems.org/pipermail/devel/2021-April/066902.html
>>
>>> I have some concerns on how this interface and libdebugger are to work?
>> Theoretically, libdebugger should be able to be implemented on top of this with
>> some additional CPU_Exception_frame and machine state manipulators. I think I
>> captured a reasonable set of generic exceptions for this purpose.
> My brief review had me wondering about the switch statement to handle the paths
> taken for each type of exception. For example a break point was in one group and
> the data abort in another however libdebugger needs everything. Is this possible?

Libdebugger can consume as many exception types as it sees fit. 
Registered handlers get the opportunity to handle every exception type 
and may opt not to as seen in the signal mapping patch.


Kinsey