I guess the distinction here is that I use kgdb for "development",
not for "debugging".
Displaying data structures, values of variables. Seeing what
state all tasks in the system are in, where they're sleeping,
where they're spending CPU, etc.
When adding ad-hoc inxtrumentation to the kernel, you don't
need to bother printing it out - just increment the counters
and go in take a look when desired.
And yes, kgdb mucks up call chains across down() because of the
lack of a frame pointer - backtraces don't display who called
down() - it loses the innermost frame. That's irritating,
but not enough to have motivated me to soil my hands with
x86 assembly yet.
I haven't had any problems with -fno-omit-frame-pointer at
any time.
I *have* had problems with -fno-inline. I'd very much like
to be able to turn that on, but the presence of `extern inline'
functions causes a link failure with `-fno-inline'. I'd suggest
that this is a gcc shortcoming. I actually had a poke yesterday
at teaching gcc to convert extern inline to static inline if
flag_no_inline, but it didn't work out.
kgdb is damned inconvenient. You have to set up a cross-build
machine, serial cable and generally get organised to use it.
In reality, this would take an hour or so but it is some friction.
I would like to see kdb shipped in the mainline kernel, so that
we can get better diagnostic reports from users/testers.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/