[PATCH v1 3/5] cpukit/microblaze: Add interrupt hooks

[Kinsey Moore]

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