GDB through QEMU doesn't catch int 3

[TheDude529]

Hi, Awesome work.

I'll get to the point with the issue above though, I don't know if this is a bug or intended, but if I plant an asm int 3 or any other sort of programmatically inserting a breakpoint, the kernel will oops rather than GDB catching it. while GDB does work and debugs the kernel correctly.

It might be due to the fact that GDB resides outside of the kernel (qemu) and the kernel is unaware of it.
Should we somehow point the main int 3 handler at the kernel to just not handle the int 3 and let it propagate upwards?

Other option could be enabling kdbg and try to connect through serial/ethernet, unpreferred though...

?

Thanks in advance!

[cirosantilli]

Hey ds,

I think this is the intended behaviour: calling the debugger requires a magic guest operation, but QEMU does not tend to have those Afaik, even for simpler things like shutting down the VM.

But worth asking in Stack Overflow + mailing list

Maybe have a look at ARM semihosting, not sure though.

I'm not sure kgdb does it by default or not, but if it does, this setup supports it out-of-the-box, so it would be easy to use: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/master/README.adoc#kgdb

However, why do you want to do this in the first place? Why not simply use b file.c:13? This way you don't have to recompile whenever you change the int location. You can then also easily save and restore breakpoints across sessions as explained at: https://stackoverflow.com/questions/501486/getting-gdb-to-save-a-list-of-breakpoints it should also be possible to use this with an IDE to save breakpoints across edits, although I haven't tried: #15