PERFORCE change 50979 for review
Marcel Moolenaar
marcel at FreeBSD.org
Tue Apr 13 00:34:45 PDT 2004
http://perforce.freebsd.org/chv.cgi?CH=50979
Change 50979 by marcel at marcel_nfs on 2004/04/13 00:34:24
Initial commit of a new tool: kgdb(1).
The files are skeletal, so there isn't anything interesting to
say about their contents. However, this is the perfect time to
explain why there's going to a be kgdb(1):
The kgdb(1) tool is an experiment (with the intention to be
committed if the experiment succeeds -- for an unspecified
definition of succeed). The primary intend is to avoid having
to add our local tweaks and hooks into gdb(1) for the sole
purpose of being able to debug kernels. These tweaks and hooks
include such things as a the -k option, the kcore pseudo
target that interfaces with libkvm and our KLD hooks.
So how is it supposed to work then? kgdb(1) is a shell on top
of gdb(1) that establishes a remote debugging session in the
same way that we can debug kernels remotely. This way, any
kernel specific details will be present in the gdb stub, which
lives in kgdb(1). This includes the interfacing with libkvm,
loading KLDs and registering those with gdb.
This setup has some nice properties and allows for some nice
features:
o There's only one way in gdb(1) to debug kernels: through a
remote target. This means that there's less code and less
variation to worry about. From a maintenance PoV a winner.
o The debugger does not need to know anything about the kernel
or its core file. Upgrading gdb(1) is easier and we don't
have a hard time changing aspects of the kernel that break
debugging, because we have everything in our own tree under
our own control. Hence, we can more easily change core file
formats mid-flight or support whatever non-standard formats
we may need.
o With kgdb(1) a shell, we can add our own set of commands to
interpret kernel data or add all kinds of conveniences into
the tool to make debugging the kernel easy.
o Since we know what we're debugging, we can more easily find
the right kernel object files that match the core file. This
may become automagical even...
The intend is to have kgdb(1) spawn gdb(1), set up the various
pipes between the two processes, pass some commands to gdb(1)
to set things up and then present the prompt. From there it
should behave no different than gdb(1).
Affected files ...
.. //depot/projects/gdb/usr.bin/kgdb/Makefile#1 add
.. //depot/projects/gdb/usr.bin/kgdb/kgdb.1#1 add
.. //depot/projects/gdb/usr.bin/kgdb/main.c#1 add
Differences ...
More information about the p4-projects
mailing list