summaryrefslogtreecommitdiffstats
path: root/share/FAQ
diff options
context:
space:
mode:
authorjoerg <joerg@FreeBSD.org>1995-03-25 12:35:00 +0000
committerjoerg <joerg@FreeBSD.org>1995-03-25 12:35:00 +0000
commit6e4dfc73964eb77495afb4fc20fc6d60dc9928d1 (patch)
treec1f08e03d112a77d12d95b9fb6e9106762c79fc8 /share/FAQ
parent1d63e7fab3f4a7c444f7bf614fe505c206ff8512 (diff)
downloadFreeBSD-src-6e4dfc73964eb77495afb4fc20fc6d60dc9928d1.zip
FreeBSD-src-6e4dfc73964eb77495afb4fc20fc6d60dc9928d1.tar.gz
Update the kernel debugging FAQ to match the new (k)gdb and new DDB
symbol behaviour.
Diffstat (limited to 'share/FAQ')
-rw-r--r--share/FAQ/Text/kernel-debug.FAQ36
1 files changed, 13 insertions, 23 deletions
diff --git a/share/FAQ/Text/kernel-debug.FAQ b/share/FAQ/Text/kernel-debug.FAQ
index 9215b26..eb07513 100644
--- a/share/FAQ/Text/kernel-debug.FAQ
+++ b/share/FAQ/Text/kernel-debug.FAQ
@@ -1,10 +1,15 @@
Kernel debugging FAQ for FreeBSD
-$Id: kernel-debug.FAQ,v 1.4 1995/01/03 15:54:03 gclarkii Exp $
+$Id: kernel-debug.FAQ,v 1.1 1995/03/21 20:19:31 jkh Exp $
*** Debugging a kernel crash dump with kgdb ***
+ [In the following, the term ``kgdb'' refers to gdb run in `kernel
+ debug mode'. This can be accomplished by either starting the gdb
+ with the option ``-k'', or by linking and starting it under the
+ name ``kgdb''. This is not being done by default, however.]
+
Here are some instructions for getting kernel debugging working on a
crash dump, it assumes that you have enough swap space for a crash
dump. If you happen to have multiple swap partitions with the first
@@ -226,32 +231,15 @@ $Id: kernel-debug.FAQ,v 1.4 1995/01/03 15:54:03 gclarkii Exp $
full debug information (including type and line number information)
like kgdb.
- To configure your kernel to include DDB, add the option lines
+ To configure your kernel to include DDB, add the option line
options DDB
- options "SYMTAB_SPACE=XXXX"
-
- to your config file, and rebuild. XXXX is the amount of space to be
- reserved into a global array DDB examines to find its symbols at run
- time. It must be large enough to hold all symbols, but not too
- large at all to avoid wasting space. 100000 Bytes are a good first
- bet for a ``normal'' kernel. The link stage will tell you about the
- usage of the symtab space, you'll see something like:
-
- dbsym: need 98765; avail 100000
- If the amount of allocated space has been too small, the above
- message is accompanied by the following error message:
-
- not enough room in db_symtab array
-
- and the link stage fails. You then need to increase the number,
- reconfig and recompile. If your config(8) has been compiled to not
- remove the old compile directory before continuing (this is a
- compile-time option [CONFIG_DONT_CLOBBER]), you need to remove
- db_aout.o prior to recompilation; this is the only file being
- affected by the SYMTAB_SPACE option.
+ to your config file, and rebuild.
+ (Note that if you have an older version of the boot blocks, your
+ debugger symbols might not be loaded at all. Update the boot
+ blocks, the recent ones do load the DDB symbols automagically.)
Once your DDB kernel is running, there are several ways to enter
DDB. The first (and most early) way is to set the boot flag `-d'
@@ -386,6 +374,8 @@ $Id: kernel-debug.FAQ,v 1.4 1995/01/03 15:54:03 gclarkii Exp $
will cause your kernel to dump core and reboot, so you can later
analyze the core on a higher level with kgdb.
+ There's now an alias for this: ``panic''.
+
call boot(0)
OpenPOWER on IntegriCloud