Nice article, but it doesn't quite deliver. It says, the trick is not "black magic", but then defines debugging in terms of ptrace syscalls, describing the API a little bit, but without giving a clue as to how ptrace actually works. So, ptrace is essentially black magic.
And this is not really an explanation of "how a debugger works," or even "how gdb works." ptrace is just one of several debug targets for gdb. There are simulators, core files, various embedded monitors, VxWorks, Windows, gdb remote debug servers over various interfaces, and on and on. ptrace is irrelevant to other targets.
It's a tragedy that ptrace is being portrayed as anything other than an entirely regrettable artifact of history. It's a terrible, terrible interface -- one of the worst in all of Unix, really (and yes, I understand the gravity of that claim). This is reminding me that I really need to write that blog post that excoriates ptrace -- and explain how frustrations with ptrace informed the development of /proc[1][2].
I've been seriously thinking of starting a podcast that layer by layer removes the "magic" behind Linux/Unix and even other OSs, even down to explaining how processors/computers in general work. I'm wondering if people like you have any interest in such a beast.
I have an episode ideas doc [1] for it that is several pages long. I need to flesh out an episode and shoot a test. After that, I need to figure out subject order.
A jitted, partially evaluation capable kernel. The thesis is very readable, proof: I could enjoy almost all of it and I'm a monkey. It might give some insights about kernel design that may not be told in mainstream ones.
Please do this! I am always so intrigued by systems, but get intimidated by just how wide and deep modern operating systems are. The world needs more technically informative podcasts. I'm a huge fan of the format, but most podcasts I've listened to, even technology ones, have been very fluffy.
Indeed, and some of the things in this article are blatantly wrong, such as using an "invalid instruction" to cause a signal we can catch.
Debuggers do NOT use invalid instructions, on x86 and AMD64 they use 0xCC (INT 0x03) on other platforms they use whatever dedicated trap-to-debugger instruction there may be, there's not usually a need to use an invalid instruction to do debugging.
I'll update the article to explain a bit more why debugging is described in terms of ptrace: all the other targets work the same way! I studied simulators and corefiles, and they both provide to GDB an interface that is very similar to ptrace. Remote debugging just applies serialization to that interface.
Not true in the embedded world. Remote gab will use tag commands, which are fascinating. Basically it's a whole different world. Processors have dedicated hardware support for debugging, far beyond traps and exceptions.
It's amazing that so many embedded processors do this now. Back in the day, you needed to use a special-purpose processor (which had extra pinouts) to do this as part of an in-circuit emulator.
I never had access to the low-level part of embedded systems, although I did my PhD on embedded systems debugging in an embedded system company! what I saw was what was running on the PC and communicating with the JTAG external interface (basically, a `gdbserver` implementation). At that level, that was nothing more than ptrace. Under that, I can't say!
And this is not really an explanation of "how a debugger works," or even "how gdb works." ptrace is just one of several debug targets for gdb. There are simulators, core files, various embedded monitors, VxWorks, Windows, gdb remote debug servers over various interfaces, and on and on. ptrace is irrelevant to other targets.