You could, but eBPF might be a more sensible way to get the same information: http://www.brendangregg.com/ebpf.html

That's comparable to DTrace. The Solaris kernel debugger, kmdb, is something else, and really worth knowing (if only it was universally adopted by C-coded kernels!).

With kmdb you get to write shell-like pipelines using powerful data structure traversal builtins, and it is safe (you can't crash the system by dereferencing NULL pointers). Really, it's quite fantastic.

curious - the Sun developers I saw in the late 90s had a multi-window debugger but the local variables Did Not Update, and had to be 'refreshed' manually; at the same time, I had MetrwoWerks IDE Debugger on a Macintosh, and easily had all locals, source code, stack, RAM inspection by structure and more, all updating with every change. The Sun devs were being PAID a LOT more, yet their tools looked primitive and the contextual knowledge to use them was much greater..

I'm not sure. I wasn't working as a kernel developer. I did have to debug stuff though to find bugs or explain certain behaviours.

I guess one reason it wasn't used much is because it was a hassle to set up, and I think it got a bit slow when you had a lot of information displayed. I do recall not using this setup much in practice, as just breaking into the debugger on the machine itself was faster and easier.

You had to lot of options when it came to working on the Solaris kernel, and the code was so easy to understand. In fact, I believe the Solaris code base is the best C code I've ever worked with. It's a pity what happened after Oracle took over.

Exactly my kind of experience learning UNIX, while coming from Amiga/PC/Mac IDE world, back in those days.

Yeah, kgdb has been mainlined for a while.

In Windows land, windbg has supported this setup for forevers too.

Of course.