freebsd-skq/gnu/usr.bin/gdb/kgdb/main.c

470 lines
11 KiB
C
Raw Normal View History

/*
* Copyright (c) 2004 Marcel Moolenaar
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <sys/param.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/resource.h>
#include <sys/select.h>
#include <sys/time.h>
#include <sys/wait.h>
#include <errno.h>
#include <err.h>
#include <inttypes.h>
#include <kvm.h>
#include <limits.h>
#include <paths.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
/* libgdb stuff. */
#include <defs.h>
#include <frame.h>
#include <frame-unwind.h>
#include <inferior.h>
#include <interps.h>
#include <cli-out.h>
#include <main.h>
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
2008-04-29 20:32:45 +00:00
#include <objfiles.h>
#include <target.h>
#include <top.h>
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
2008-04-29 20:32:45 +00:00
#include <ui-file.h>
#include <bfd.h>
#include <gdbcore.h>
#include <wrapper.h>
extern frame_unwind_sniffer_ftype *kgdb_sniffer_kluge;
#include "kgdb.h"
static int dumpnr;
static int quiet;
static int verbose;
static char crashdir[PATH_MAX];
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
2008-04-29 20:32:45 +00:00
static char *kernel;
static char *remote;
static char *vmcore;
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
2008-04-29 20:32:45 +00:00
static struct ui_file *parse_gdberr;
static void (*kgdb_new_objfile_chain)(struct objfile * objfile);
static void
usage(void)
{
fprintf(stderr,
"usage: %s [-afqv] [-d crashdir] [-c core | -n dumpnr | -r device]\n"
"\t[kernel [core]]\n", getprogname());
exit(1);
}
static void
kernel_from_dumpnr(int nr)
{
char path[PATH_MAX];
FILE *info;
char *s;
struct stat st;
int l;
/*
* If there's a kernel image right here in the crash directory, then
* use it. The kernel image is either called kernel.<nr> or is in a
* subdirectory kernel.<nr> and called kernel. The latter allows us
* to collect the modules in the same place.
*/
snprintf(path, sizeof(path), "%s/kernel.%d", crashdir, nr);
if (stat(path, &st) == 0) {
if (S_ISREG(st.st_mode)) {
kernel = strdup(path);
return;
}
if (S_ISDIR(st.st_mode)) {
snprintf(path, sizeof(path), "%s/kernel.%d/kernel",
crashdir, nr);
if (stat(path, &st) == 0 && S_ISREG(st.st_mode)) {
kernel = strdup(path);
return;
}
}
}
/*
* No kernel image here. Parse the dump header. The kernel object
* directory can be found there and we probably have the kernel
* image still in it. The object directory may also have a kernel
* with debugging info (called kernel.debug). If we have a debug
* kernel, use it.
*/
snprintf(path, sizeof(path), "%s/info.%d", crashdir, nr);
info = fopen(path, "r");
if (info == NULL) {
warn(path);
return;
}
while (fgets(path, sizeof(path), info) != NULL) {
l = strlen(path);
if (l > 0 && path[l - 1] == '\n')
path[--l] = '\0';
if (strncmp(path, " ", 4) == 0) {
s = strchr(path, ':');
s = (s == NULL) ? path + 4 : s + 1;
l = snprintf(path, sizeof(path), "%s/kernel.debug", s);
if (stat(path, &st) == -1 || !S_ISREG(st.st_mode)) {
path[l - 6] = '\0';
if (stat(path, &st) == -1 ||
!S_ISREG(st.st_mode))
break;
}
kernel = strdup(path);
break;
}
}
fclose(info);
}
static void
kgdb_new_objfile(struct objfile *objfile)
{
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
2008-04-29 20:32:45 +00:00
static int once = 1;
kld_new_objfile(objfile);
kgdb_trgt_new_objfile(objfile);
if (kgdb_new_objfile_chain != NULL)
kgdb_new_objfile_chain(objfile);
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
2008-04-29 20:32:45 +00:00
if (once && objfile != NULL && objfile == symfile_objfile) {
/*
* The initial kernel has just been loaded. Start the
* remote target if we have one.
*/
once = 0;
if (remote != NULL)
push_remote_target (remote, 0);
}
}
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
2008-04-29 20:32:45 +00:00
/*
* Parse an expression and return its value. If 'quiet' is true, then
* any error messages from the parser are masked.
*/
CORE_ADDR
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
2008-04-29 20:32:45 +00:00
kgdb_parse_1(const char *exp, int quiet)
{
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
2008-04-29 20:32:45 +00:00
struct ui_file *old_stderr;
struct cleanup *old_chain;
struct expression *expr;
struct value *val;
char *s;
CORE_ADDR n;
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
2008-04-29 20:32:45 +00:00
old_stderr = gdb_stderr;
if (quiet)
gdb_stderr = parse_gdberr;
n = 0;
s = xstrdup(exp);
old_chain = make_cleanup(xfree, s);
if (gdb_parse_exp_1(&s, NULL, 0, &expr) && *s == '\0') {
make_cleanup(free_current_contents, &expr);
if (gdb_evaluate_expression(expr, &val))
n = value_as_address(val);
}
do_cleanups(old_chain);
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
2008-04-29 20:32:45 +00:00
gdb_stderr = old_stderr;
return (n);
}
#define MSGBUF_SEQ_TO_POS(size, seq) ((seq) % (size))
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
2008-04-29 20:32:45 +00:00
void
kgdb_dmesg(void)
{
CORE_ADDR bufp;
int size, rseq, wseq;
char c;
/*
* Display the unread portion of the message buffer. This gives the
* user a some initial data to work from.
*/
if (quiet)
return;
bufp = kgdb_parse("msgbufp->msg_ptr");
size = (int)kgdb_parse("msgbufp->msg_size");
if (bufp == 0 || size == 0)
return;
rseq = (int)kgdb_parse("msgbufp->msg_rseq");
wseq = (int)kgdb_parse("msgbufp->msg_wseq");
rseq = MSGBUF_SEQ_TO_POS(size, rseq);
wseq = MSGBUF_SEQ_TO_POS(size, wseq);
if (rseq == wseq)
return;
printf("\nUnread portion of the kernel message buffer:\n");
while (rseq < wseq) {
read_memory(bufp + rseq, &c, 1);
putchar(c);
rseq++;
if (rseq == size)
rseq = 0;
}
if (c != '\n')
putchar('\n');
putchar('\n');
}
static void
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
2008-04-29 20:32:45 +00:00
kgdb_init(char *argv0 __unused)
{
parse_gdberr = mem_fileopen();
set_prompt("(kgdb) ");
initialize_kgdb_target();
initialize_kld_target();
kgdb_new_objfile_chain = target_new_objfile_hook;
target_new_objfile_hook = kgdb_new_objfile;
}
/*
* Remote targets can support any number of syntaxes and we want to
* support them all with one addition: we support specifying a device
* node for a serial device without the "/dev/" prefix.
*
* What we do is to stat(2) the existing remote target first. If that
* fails, we try it with "/dev/" prepended. If that succeeds we use
* the resulting path, otherwise we use the original target. If
* either stat(2) succeeds make sure the file is either a character
* device or a FIFO.
*/
static void
verify_remote(void)
{
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
2008-04-29 20:32:45 +00:00
char path[PATH_MAX];
struct stat st;
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
2008-04-29 20:32:45 +00:00
if (stat(remote, &st) != 0) {
snprintf(path, sizeof(path), "/dev/%s", remote);
if (stat(path, &st) != 0)
return;
free(remote);
remote = strdup(path);
}
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
2008-04-29 20:32:45 +00:00
if (!S_ISCHR(st.st_mode) && !S_ISFIFO(st.st_mode))
errx(1, "%s: not a special file, FIFO or socket", remote);
}
static void
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
2008-04-29 20:32:45 +00:00
add_arg(struct captured_main_args *args, char *arg)
{
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
2008-04-29 20:32:45 +00:00
args->argc++;
args->argv = reallocf(args->argv, (args->argc + 1) * sizeof(char *));
if (args->argv == NULL)
err(1, "Out of memory building argument list");
args->argv[args->argc] = arg;
}
int
main(int argc, char *argv[])
{
char path[PATH_MAX];
struct stat st;
struct captured_main_args args;
char *s;
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
2008-04-29 20:32:45 +00:00
int a, ch;
dumpnr = -1;
strlcpy(crashdir, "/var/crash", sizeof(crashdir));
s = getenv("KGDB_CRASH_DIR");
if (s != NULL)
strlcpy(crashdir, s, sizeof(crashdir));
/* Convert long options into short options. */
for (a = 1; a < argc; a++) {
s = argv[a];
if (s[0] == '-') {
s++;
/* Long options take either 1 or 2 dashes. */
if (s[0] == '-')
s++;
if (strcmp(s, "quiet") == 0)
argv[a] = "-q";
else if (strcmp(s, "fullname") == 0)
argv[a] = "-f";
}
}
quiet = 0;
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
2008-04-29 20:32:45 +00:00
memset (&args, 0, sizeof args);
args.use_windows = 0;
args.interpreter_p = INTERP_CONSOLE;
args.argv = malloc(sizeof(char *));
args.argv[0] = argv[0];
while ((ch = getopt(argc, argv, "ac:d:fn:qr:vw")) != -1) {
switch (ch) {
case 'a':
annotation_level++;
break;
case 'c': /* use given core file. */
if (vmcore != NULL) {
warnx("option %c: can only be specified once",
optopt);
usage();
/* NOTREACHED */
}
vmcore = strdup(optarg);
break;
case 'd': /* lookup dumps in given directory. */
strlcpy(crashdir, optarg, sizeof(crashdir));
break;
case 'f':
annotation_level = 1;
break;
case 'n': /* use dump with given number. */
dumpnr = strtol(optarg, &s, 0);
if (dumpnr < 0 || *s != '\0') {
warnx("option %c: invalid kernel dump number",
optopt);
usage();
/* NOTREACHED */
}
break;
case 'q':
quiet = 1;
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
2008-04-29 20:32:45 +00:00
add_arg(&args, "-q");
break;
case 'r': /* use given device for remote session. */
if (remote != NULL) {
warnx("option %c: can only be specified once",
optopt);
usage();
/* NOTREACHED */
}
remote = strdup(optarg);
break;
case 'v': /* increase verbosity. */
verbose++;
break;
case 'w': /* core file is writeable. */
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
2008-04-29 20:32:45 +00:00
add_arg(&args, "--write");
break;
case '?':
default:
usage();
}
}
if (((vmcore != NULL) ? 1 : 0) + ((dumpnr >= 0) ? 1 : 0) +
((remote != NULL) ? 1 : 0) > 1) {
warnx("options -c, -n and -r are mutually exclusive");
usage();
/* NOTREACHED */
}
if (verbose > 1)
warnx("using %s as the crash directory", crashdir);
if (argc > optind)
kernel = strdup(argv[optind++]);
if (argc > optind && (dumpnr >= 0 || remote != NULL)) {
warnx("options -n and -r do not take a core file. Ignored");
optind = argc;
}
if (dumpnr >= 0) {
snprintf(path, sizeof(path), "%s/vmcore.%d", crashdir, dumpnr);
if (stat(path, &st) == -1)
err(1, path);
if (!S_ISREG(st.st_mode))
errx(1, "%s: not a regular file", path);
vmcore = strdup(path);
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
2008-04-29 20:32:45 +00:00
} else if (remote != NULL) {
verify_remote();
} else if (argc > optind) {
if (vmcore == NULL)
vmcore = strdup(argv[optind++]);
if (argc > optind)
warnx("multiple core files specified. Ignored");
} else if (vmcore == NULL && kernel == NULL) {
vmcore = strdup(_PATH_MEM);
kernel = strdup(getbootfile());
}
if (verbose) {
if (vmcore != NULL)
warnx("core file: %s", vmcore);
if (remote != NULL)
warnx("device file: %s", remote);
if (kernel != NULL)
warnx("kernel image: %s", kernel);
}
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
2008-04-29 20:32:45 +00:00
/* A remote target requires an explicit kernel argument. */
if (remote != NULL && kernel == NULL) {
warnx("remote debugging requires a kernel");
usage();
/* NOTREACHED */
}
/* If we don't have a kernel image yet, try to find one. */
if (kernel == NULL) {
if (dumpnr >= 0)
kernel_from_dumpnr(dumpnr);
if (kernel == NULL)
errx(1, "couldn't find a suitable kernel image");
if (verbose)
warnx("kernel image: %s", kernel);
}
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
2008-04-29 20:32:45 +00:00
add_arg(&args, kernel);
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
2008-04-29 20:32:45 +00:00
if (vmcore != NULL)
add_arg(&args, vmcore);
/* The libgdb code uses optind too. Reset it... */
optind = 0;
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
2008-04-29 20:32:45 +00:00
/* Terminate argv list. */
add_arg(&args, NULL);
init_ui_hook = kgdb_init;
kgdb_sniffer_kluge = kgdb_trgt_trapframe_sniffer;
return (gdb_main(&args));
}