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