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

Kinsey Moore kinsey.moore at oarcorp.com
Fri Feb 18 22:34:48 UTC 2022


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



More information about the devel mailing list