Context switch during stepping causes weird behavior

John Baldwin
Wed Oct 5 16:53:59 GMT 2022

On 10/4/22 11:48 PM, Adrian Oltean wrote:
> Hi John,
> Thanks for sharing your experience. I'm also planning to recommend our customers to use breakpoints instead of actual step operations. However, I still don't like the uncontrollable GDB when stepping and kernel thread gets moved. In your case, I see a friendlier behavior - at least stepping stops at some point, even though not reaching the expected code section. This would be my goal as well. Maybe someone can suggest how to patch the GDB code in order to suspend the step when GDB detects that stepping thread is actually changed. Unfortunately, I don't have much knowledge about the GDB code and all my attempts failed so far.

I wonder if the difference is due to the use of displaced stepping?
FreeBSD doesn't support displaced stepping.  I don't know off the top
of my head if there is a knob to disable displaced stepping.  If there
is, you might try doing that to see if you get the type of behavior I
see where the debugger stops because a step ends up out of bounds.

> Thank you,
> Adrian
> -----Original Message-----
> Interrupts make single-stepping on bare-metal or OS kernels hard.  When doing similar things for debugging FreeBSD's kernel via bare-metal stubs (e.g. in QEMU or in FreeBSD's hypervisor) I generally use 'until' and/or breakpoints instead to work around this rather than using normal stepping.
> On the GDB server side (for the GDB stub in FreeBSD's hypervisor) I've thought about doing odd things like trying to defer interrupts while stepping but there isn't a really good way to deal with that in general.
> (Most of the time when trying to step what happens for me is that I get a reported stop back for a PC in the timer interrupt handler for the local APIC timer interrupt, and then GDB sees that the PC is "out of range" and just stops at that point)
> --
> John Baldwin

John Baldwin

More information about the Gdb mailing list