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: >>>> 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. > In other architectures (at least AArch64 and I believe ARM as well, I make no > claims as to how i386 operates), transition to interrupt/exception context > implicitly disables hardware breakpoints and other debugging modes and they > must > be explicitly re-enabled to encounter this type of problem.
Hardware and software breakpoint to some extent are under the control of GDB. On a i386 a software break point in code used to handle the break point handler would nest until the stack was blown. >>>> 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? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel