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