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. >> 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. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel