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

[Kinsey Moore]

On 2/17/2022 20:31, Chris Johns wrote:
> 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:
>>>>> 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?
In the nominal case (libdebugger not running), the overhead is less than 
30 instructions per interrupt execution which could theoretically be 
optimized a bit by integrating the handler dispatch into the ISR_Handler 
assembly instead of having it be a stand-alone C function. In the case 
where libdebugger is running, the overhead is the nominal overhead plus 
O(n) on the number of software breakpoints installed. If I had to hazard 
a guess on the incremental number of instructions per software break, 
I'd put it at 50 or so on top of the overhead of the call chain to get 
there.

Kinsey