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

[Kinsey Moore]

On 2/18/2022 14:37, Gedare Bloom wrote:
> On Fri, Feb 18, 2022 at 6:50 AM Kinsey Moore <kinsey.moore at oarcorp.com> wrote:
>> 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
> I think this will be undesirable in production. Can we find a way to
> make it conditional compilation?
As mentioned in the RTEMS discord, I'm going to pursue elimination of 
the interrupt hooks in favor of a slight change to the behavior of 
libdebugger on software break in interrupt context that should solve 
similar issues across all libdebugger backends that use software breaks 
in any capacity.

Kinsey