Submitted by Well-known Haiku kernel hacker Ingo Weinhold has written an in-depth guide to using the Haiku kernel debugger. It describes the most important commands, introduces the recently added kernel tracing feature, and concludes with an example KDL session in which Ingo debugs an inter application deadlock. A recommended read, especially if you are a Haiku hacker or interested in becoming one.
> It describes the most important commands
Then where is kdlhangman cited ?
Hopefully ppl will be less afraid of KDL now
If only I had this info when I was trying to debug my sound driver for BeOS. I think Haiku is going to be fun to program for.
Kernel debugging is pretty fun. It’s like diagnosing a patient through an autopsy or exploratory surgery. You can’t see everything (particularly, dynamic behavior is nearly impossible to capture without extensive tracing or something like DTrace), so you have to make hypotheses and see if the state you see in the debugger matches. It’s also an interesting challenge to find the correct place to put a breakpoint so that you get only the path you’re interested in and not some other path. It’s hard to get started on this, though, unless you have enough knowledge of the system you want to debug and some specific issue to attack.
I guess it could be thru a serial cable, and a second computer where you can access reference material. For me using it on the ‘wrecked’ machine directly it’s a bit to constrained when you can’t go outside KDL.
I guess many app-programmers have this simpler setup, and therefore can’t use KDL in the best way.
Apps programmers are not required to use KDL. Like under BeOS, Haiku have builtin userland debug support, via gdb for the moment, but graphical frontend(s) or native source debugger(s) will comes too.
KDL is only useful for kernel stuffs programming. While today it include Haiku’s kernel core itself and running an app can lead one to KDL, the reason is not the app but kernel issues, where KDL help greatly. More and more it will be useful for drivers and kernel add-ons developers, but useless for apps programmers.
Well, except for the ones who are addict to hangman game, that is.
No, they arn’t. It was mentioned, dunno if it was in the article or the comments, that it was a shame that app-devs don’t use KDL more than they do.
One point of the article was to show how useful the KDL can be for userland bugs too. The demonstration at the end debugs a *userland* problem. It does help greatly to have a second machine to be able to look at the source in parallel, that’s for sure. The particular example problem was tracked down in QEMU. So you can do it on the same computer. QEMU even supports a virtual serial connection to the guest system. I think it is possible to attach GDB to any running process and get a stack trace from that and all. But the guide shows exactly how easy the same thing is from within KDL, with tons of more features like printing the owner or last aquirerer of a semaphore and so on. I don’t even know how to do that in GDB or if it’s even possible. Let alone the cool new tracing support. While GDB runs in textmode on Haiku, I find the KDL is at least as useful, probably more.