it to recognise what ABI to use on amd64 (and possibly others) platform.
Display PID and process name as a part of the 'info threads' output, TIDs
alone are too confusing. Introduce new commmands 'tid <tid>' and 'proc <pid>'
to accompany gdb's default 'thread <thread num>' to make the task of switching
between different contexts easier.
Document all options and general usage.
Implement the -a option to bump the annotation_level. This improves
the Emacs gud behaviour. You can now supply the following function
(defun gud-gdb-massage-args (file args) (cons "-a" args))
(e.g. by evaluating it from the *scratch* buffer) and get the normal
jump to the source window when browsing the stack.
We should probably eventually supply our own kgdb submode to gud.el.
Implement the -a option to bump the annotation_level. This improves
the Emacs gud behaviour. You can now supply the following function
(defun gud-gdb-massage-args (file args) (cons "-a" args))
(e.g. by evaluating it from the *scratch* buffer) and get the normal
jump to the source window when browsing the stack.
We should probably eventually supply our own kgdb submode to gud.el.
make sure it is a device. GDB special cases these prefixes and treats
:#### as a tcp port on localhost and executes what ever follows '|'.
This allows kgdb to debug via dconschat.
Discussed with: marcel
with the currently running kernel image. Otherwise, one of -c, -n or
-r is expected for working on a particular core file (-c), working
on a saved dump (-n) or working remotely (-r). When working on a
saved dump, a kernel may be omitted.
For a remote debugging session (-r), kgdb(1) will use the specified
device.
is basicly a shell on top of libgdb that knows about kernel threads,
kernel modules and kvm(3). As the word "beginnings" implies, not
all of the features have been implemented yet. The tool is useful
and I'd like feedback on the taken route.
The simplest way to debug a kernel core file is:
kgdb -n 0
This opens /var/crash/vmcore.0 with the corresponding kernel in
the object directory (kernel.debug is used if it exists).
Typical things that need to be added are:
o Auto loading of kernel modules,
o Handling of trapframes so that backtraces can be taken across
them,
o Some fancy commands to extract useful information out of a core
file,
o Various (probably many) other things.
