kdb_cmds: new (returning) user questions
scott.lurndal at 3leafnetworks.com
Tue May 15 16:44:40 PDT 2007
On Tue, May 15, 2007 at 04:42:45PM -0700, Randy.Dunlap wrote:
> I have a few basic questions.
> 1. Is there a way to "import" custom kdb commands other than
> putting them into kdb_cmds and rebuilding the kernel?
The traditional method is to create a loadable kernel module which
registers a command using kdb_register. There are several examples
in the KDB patch.
> 2. I'd like to be able to "bc all" (or "bca"). or I can put
> that into a custom defcmd... Should I just do the latter?
One difficultly with loadable kernel modules is that they only
have access symbols in the base KDB that have been exported. You
may not have access to all the symbols to implement bc all in
a module-based command.
> 3. I often need to use what some debuggers call "step over",
> i.e., execute a call instruction and break after it returns,
> immediately after the call instruction. Does kdb already have
> this command and I just don't see it? Currently I just use:
> defcmd soc "" "step over call"
> bp %rip+5 # CPU-specific
> but that leaves me with (should be temporary) breakpoints that
> should be deleted ASAP. Can I determine what bpnum was used and
> then clear it later? (although I don't know when I would clear it)
I don't believe this capability exists at this point; Keith may have
something in progress for this. There is a flavor of ss that
will single step to the next branch-type instruction, but nothing that
can be used to step -over- a call (e.g. step vs. next).
> 4. Is there a way to print (decode) the CPU flags register so that
> I can see which bits (conditions) are set/clear?
Not aware of a method for this. This is something that a module
registered command could implement.
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
More information about the kdb