> Well that's all fine & good if you have the extra dumb (or not-so-dumb)
> terminals lying around to use it, but not everyone does. Furthermore,
> getting things "set-up" for kgdb is just a PITA compared to kdb just
> working as OOOPS happen (again, who wants to dedicate a machine to kgdb
> full-time?). Perhaps what might be done is to merge the two debuggers
For oopses crash dumps are actually more practical.
You have two main use cases:
- Serious debugging of broken code. Nothing can beat source level
here, assembly level is just a pita.
- Post Mortem Analysis after a crash
Tools like crash or lkcd do this quite well, with less overhead.
kdb sits somewhere inbetween, but does nothing well.
> to give the user the choice of in-kernel debugging or remote core
> debugging. In other words, make the debugging of ooops/panics a boot
> argument? I don't know much about kgdb, so as to how practical this
> might be is another question.
It's not practical. kdb is much more complex than kgdb.
There used to be a user land proxy to run kdb from kgdb, but it never
worked really well and the latest kgdb stubs are much more powerful.
-Andi (who worked on a KDB port to another architecture, but gave up
and switched to kgdb because implementing dwarf2 unwinding in the kernel is
just too ugly)