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

[Gedare Bloom]

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?

>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel