Copy stable/10@r272459 to releng/10.1 as part of
the 10.1-RELEASE process.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

kgdb enhancements!

* document the kgdb -b flag
* better verify what's valid with -b
* add more comprehensive command line help

PR: kern/175743
Submitted by: Christoph Mallon <christoph.mallon@gmx.de>

Add command-line support to kgdb to allow the baudrate to be set.

This allows a remote session to be specified with '-r' as well as a
non-default baudrate setting using '-b'.

TODO: add to the kgdb manpage.

MFC after: 2 weeks

Add missing -w to kgdb(1)'s usage().

Sponsored by: Adara Networks, Inc.
MFC after: 3 days

Use string literal format strings to quiet clang warnings.

Move test for zero bufp or size before rseq and wseq calculation. This
avoids spinning in an infinite loop for some (possibly corrupt?) core
files at work.

Rework how kgdb manages kernel and vmcore files to be a bit more gdb-ish
so that kgdb can be used more like a normal gdb:
- Load the kernel via the standard 'exec' target and allow it to be changed
via the 'file' command.
- Instead of explicitly loading the kernel file as the mail symbol file
during startup, just pass it to gdb_main() as the executable file.
- Change the kld support (via shared libraries) to cache the address of
the linker_files and linker_kernel_file variables in addition to the
offsets of various members in 'struct linker_file'.
- When a new symbol file is loaded, recompute the addresses and offsets
used by the kld support code.
- When a new symbol file is loaded, recalculate the ofs_fix variable to
account for the different ways a trapframe can be passed to trap
frame handlers in i386. This is done by adding a MD
kgdb_trgt_new_objfile() hook that is empty on all but i386.
- Don't use the directory name of the kernel specified on the command
line to find kernel modules in the kld support code. Instead,
extract the filename of the current executable via exec_bfd. Now
the 'kernel' variable is private to main.c again.
- Make the 'add-kld' command explicitly fail if no executable is loaded.
- Make the support for vmcores a real core-dump target that opens the
kernel and vmcore on open and closes the kvm connection when closed, etc.
- The 'core' command can now be used to select a vmcore to use, either
a crash dump file or /dev/mem for live debugging.
- The 'detach' command can be used to detach from a vmcore w/o attaching
to a new one.
- kgdb no longer explicitly opens a core dump during startup and no longer
has to use an atexit() hook to close the kvm connection on shutdown.
- Symbols for kld's are automatically loaded anytime a core is opened.
Also, the unread portion of dmesg is dumped just as it was done on kgdb
startup previously.
- Don't require either a remote target or core dump if a kernel is specified.
You can now just run 'kgdb kernel' similar to running gdb on an executable
and later connect to a remote target or core dump.
- Use a more relaxed way to verify remote targets specified via -r.
Instead of explicitly allowing a few non-file target specifications,
just assume that if stat() on the arg and on "/dev/" + arg both fail
that is some non-file target and pass it to gdb.
- Don't use a custom interpreter. The existing kgdb_init() hook and the
target_new_objfile() hook give us sufficient hooks during startup to
setup kgdb-specific behavior now.
- Always add the 'proc', 'tid', and 'add-kld' commands on startup and not
just if we have a core dump. Currently the 'proc' and 'tid' commands do
not work for remote targets (I will fix at least 'tid' in the next round
of changes though). However, the 'add-kld' command works fine for
loading symbols for a kernel module on a remote target.
- Always setup the 'kld' shared library target operations instead of just
if we have a core dump. Although symbols for kernel modules are not
automatically loaded when connecting to a remote target, you can do
'info sharedlibrary' after connecting to the remote target and kgdb will
find all the modules. You can then use the 'sharedlibrary' command to
load symbols from the module files.
- Change kthr_init() to free the existing list of kthr objects before
generating a new one. This allows it to be invoked multiple times
w/o leaking memory.

MFC after: 1 week

Change kgdb_parse() to use wrapped versions of parse_expression() and
evaluate_expression() so that any errors are caught and cause the function
to return to 0. Otherwise the errors posted an exception (via longjmp())
that aborted the current operation. This fixes the kld handling for
older kernels (6.x and 7.x) that don't have the full pathname stored in
the kernel linker.

MFC after: 3 days

Don't close the kernel bfd object during startup. Instead, leave it open
and build a section table from the kernel file so that 'info files' output
for kgdb now matches the usage of gdb on a regular file with the exception
that we don't list sections for memory in the crash dump.

If the quiet flag is specified (-q), don't dump the unread portion of
the message buffer on startup.

Add a new 'add-kld <kld>' command to kgdb to make it easier to analyze
crash dumps with kernel modules. The command is basically a wrapper
around add-symbol-file except that it uses the kernel linker data
structures and the ELF section headers of the kld to calculate the
section addresses add-symbol-file needs.

The 'kld' parameter may either be an absolute path or a relative path.
kgdb looks for the kld in several locations checking for variants with
".symbols" or ".debug" suffixes in each location. The first location it
tries is just opening the specified path (this handles absolute paths and
looks for the kld relative to the current directory otherwise). Next
it tries to find the module in the same directory of the kernel image
being used. If that fails it extracts the kern.module_path from the
kernel being debugged and looks in each of those paths.

The upshot is that for the common cases of debugging /boot/kernel/kernel
where the module is in either /boot/kernel or /boot/modules one can merely
do 'add-kld foo.ko'.

MFC after: 1 week

Add -w parameter which tells kgdb to open kmem-based targets in read-write
mode. This allows one to use kgdb on /dev/mem and be able to patch memory
on a live system. This is identical to what -wcore used to do in previous
gdb versions for FreeBSD.

Requested by: wpaul

Fix dump of the unread portion of the kernel message buffer.

PR: bin/87964
Submitted by: Frank Mayhar frank at exit dot com

Add a kluge to allow kgdb(1) to inject its own frame sniffer in the
list of frame sniffers so that trapframes can be detected. The kluge
is needed because this version of gdb only supports appending a
sniffer to the list of sniffers and the moment kgdb gets a chance to
add its own frame sniffer, the target's default frame sniffer is
already in the list. Since the default frame sniffer claims any
frame thrown at it, kgdb's frame sniffer never gets to smell (a
process much akin to tasting, but with lesser chance of hurling :-)

This commit adds dummy frame sniffers that never claim a frame and
as such don't fix anything yet. However, we now have frame sniffers
and they are being called, so it's just a matter of adding meat to
the bones and we'll be able to properly unwind across trapframes.

MFC after: 1 week

o As mentioned in the previous commit: make the KVM error buffer
static.
o Register a function with atexit(3) to close the KVM object if
we have one open.
o Show the unread portion of the kernel's message buffer before
presenting the prompt. It's bound to provide some useful info.
o Don't call kgdb_target() twice. It results in having all threads
listed twice.

MFC after: 1 week

kvm_openfiles() uses the supplied buffer for storing error messages
in future calls, so we can't free it here. The right place to free the
buffer would be to be after kvm_close(), but we don't do that yet. A
static buffer would work too.

Reviewed by: marcel (who has other plans for this anyway)
Approved by: re

Implement and document the -q and -f options with their corresponding
long form (-quiet and -fullname resp.) Bump documentation date.

PR: bin/78031
MFC after: 5 days

Attempt to make kgdb little more useful and easy to use. Properly initialize
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.

[Sorry, forgot to commit my source changes in my previous commit.]
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.

If the argument to the -r flag starts with a ':' or a '|', don't try to
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

Improve the usage. Without any arguments, kgdb(1) works on /dev/mem
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.

Add the beginnings of kernel debugging support. the kgdb(1) tool
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.