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.
lwp ID before invoking the underlying target operation.
For corefiles, we rely on gdb internals to do this, and it uses the
pid as an index, rather than the lwpid, so previously, backtraces
for multithreaded core files wasn't working correctly. For processes,
we currently use ptrace directly, so fixup that code to also use
the pid directly.
Discussed With: marcel, davidxu
MFC After: 4 days
solib-svr4.c to the MD makefiles because they are native files for
alpha and sparc64, but target files for amd64, i386 and ia64.
Note that kgdb(1) does not yet build as a cross-debugger due to
libkvm.
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.
changes, start on a new line. Insertion of a filename will keep the
diff limited to the block of filenames that have the same first letter
instead of creating a huge diff. While here, move remote.c after the
remote-*.c files and move tui.c after the tui-*.c files. This matches
the order of ls(1) and makes it easier to compare object files created
by a stock gdb(1) build with the list of files we have here.
This is a non-functional change only.
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.
that have been added to <sys/procfs.h>. This change has no effect
because the source file that would be affected is not compiled on
FreeBSD. Hence, this is for completeness only.
