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

[Chris Johns]

On 18/2/22 8:58 am, Kinsey Moore wrote:
> 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.

Hardware and software breakpoint to some extent are under the control of GDB.

On a i386 a software break point in code used to handle the break point handler
would nest until the stack was blown.

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

Hmm .. the GDB solution is to place the instruction back and step then return
the break point. I am not sure if this is possible and less intrusive to the system?

Does this solution means the interrupts have extra overheads?

Chris