Context switch during stepping causes weird behavior

Adrian Oltean adrian.oltean@nxp.com
Wed Oct 5 06:48:44 GMT 2022


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.

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


More information about the Gdb mailing list