On 2/17/2022 15:31, Chris Johns wrote:
On 18/2/22 7:12 am, Kinsey Moore wrote:
On 2/17/2022 13:53, Chris Johns wrote:
On 16/2/22 7:38 am, Kinsey Moore wrote:
Add hooks for manipulating system state before and after interrupts are
run. These hooks serve primarily to allow the MicroBlaze libdebugger
backend to prevent software breaks from occurring in interrupt context.
I am unsure what problem this is resolving?
This is resolving an issue specific to libdebugger backends that use only
software breaks without any additional architecture support. When entering
interrupt context, breakpoints of all varieties must be disabled or libdebugger
may be called into from interrupt context which libdebugger ignores as something
that needs to be passed to the fatal error handler. Microblaze in particular has
no way to set hardware breakpoints, watchpoints, or single-step operation from
the CPU (even if they exist in some configurations) and no way to disable
software breaks upon entry to interrupt context without hooks of this variety.
Why is this specific to software break points? A hardware break point in a
similar situation will trigger an exception.
In other architectures (at least AArch64 and I believe ARM as well, I
make no claims as to how i386 operates), transition to
interrupt/exception context implicitly disables hardware breakpoints and
other debugging modes and they must be explicitly re-enabled to
encounter this type of problem.
Who is setting breaks points in interrupts?
Where I encountered issues was setting breaks in library functions that I was
stepping through in non-interrupt context, particularly in memset(). ISR
handlers can also call into this library code and libdebugger bails when
application debugging intersects with ISR handler execution.
Interesting use case. Does this effect all archs? I think it does.
It does to an extent. Stepping through with inverse breakpoints on ARM
and single-step mode on AArch64 wouldn't encounter this issue, but
software breakpoints placed in those shared functions would cause the
same problems I'm seeing on MicroBlaze. ARM may not see this issue at
all if it makes hardware breakpoints available, but I don't remember
whether it does.
Kinsey
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
