aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
diff options
context:
space:
mode:
authorNik Clayton <nik@FreeBSD.org>1999-01-30 23:35:05 +0000
committerNik Clayton <nik@FreeBSD.org>1999-01-30 23:35:05 +0000
commit7321b94099016efbe3b05e82b2ed7d908e84cd99 (patch)
tree75507fdab8310f4a663cc66b24c28592f3dea9ae /en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
parent84b6327dc093291e25fb79dfb80cb75f0543f697 (diff)
downloaddoc-7321b94099016efbe3b05e82b2ed7d908e84cd99.tar.gz
doc-7321b94099016efbe3b05e82b2ed7d908e84cd99.zip
Suddenly realised none of the
<informalexample> <screen> ... </screen> </informalexample> need the <informalexample> element. So remove it. Simple search and replace does the trick.
Notes
Notes: svn path=/head/; revision=4157
Diffstat (limited to 'en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml')
-rw-r--r--en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml128
1 files changed, 64 insertions, 64 deletions
diff --git a/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
index 796252e1d3..2507290ae1 100644
--- a/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
+++ b/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
@@ -61,12 +61,12 @@ Dumps to non-swap devices, tapes for example,
single user state using the <option>-s</option> flag at the boot
prompt, and then perform the following steps:</para>
- <informalexample>
+
<screen>&prompt.root; <userinput>fsck -p</userinput>
&prompt.root; <userinput>mount -a -t ufs</userinput> # so your file system for /var/crash is writable
&prompt.root; <userinput>savecore -N /kernel.panicked /var/crash</userinput>
&prompt.root; <userinput>exit</userinput> # ...to multi-user</screen>
- </informalexample>
+
<para>This instructs <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> to
use another kernel for symbol name extraction. It would otherwise
@@ -78,11 +78,11 @@ Dumps to non-swap devices, tapes for example,
<filename>/sys/compile/WHATEVER</filename> and run <command>kgdb</command>. From <command>kgdb</command>
do:
- <informalexample>
+
<screen><userinput>symbol-file kernel.debug</userinput>
<userinput>exec-file /var/crash/kernel.0</userinput>
<userinput>core-file /var/crash/vmcore.0</userinput></screen>
- </informalexample>
+
and voila, you can debug the crash dump using the
kernel sources just like you can for any other program.</para>
@@ -93,7 +93,7 @@ Dumps to non-swap devices, tapes for example,
Despite this, it is a real-world error trace taken during the
development of the pcvt console driver.</para>
- <informalexample>
+
<screen> 1:Script started on Fri Dec 30 23:15:22 1994
2:&prompt.root; <userinput>cd /sys/compile/URIAH</userinput>
3:&prompt.root; <userinput>kgdb kernel /var/crash/vmcore.1</userinput>
@@ -174,7 +174,7 @@ Dumps to non-swap devices, tapes for example,
78:exit
79:
80:Script done on Fri Dec 30 23:18:04 1994</screen>
- </informalexample>
+
<para>Comments to the above script:</para>
@@ -247,9 +247,9 @@ Dumps to non-swap devices, tapes for example,
option to the <command>ddd</command> command line you would use
normally. For example;</para>
- <informalexample>
+
<screen>&prompt.root; <userinput>ddd -k /var/crash/kernel.0 /var/crash/vmcore.0</userinput></screen>
- </informalexample>
+
<para>You should then be able to go about looking at the crash dump using
<command>ddd</command>'d graphical interface.</para>
@@ -348,10 +348,10 @@ options DDB</programlisting> to your config file, and rebuild. (See <link
<para>The DDB commands roughly resemble some <command>gdb</command> commands. The first thing you probably
need to do is to set a breakpoint:</para>
- <informalexample>
+
<screen><userinput>b function-name</userinput>
<userinput>b address</userinput></screen>
- </informalexample>
+
<para>Numbers are taken hexadecimal by default, but to make them
distinct from symbol names; hexadecimal numbers starting with the
@@ -362,15 +362,15 @@ options DDB</programlisting> to your config file, and rebuild. (See <link
<para>To continue the operation of an interrupted kernel, simply type:</para>
- <informalexample>
+
<screen><userinput>c</userinput></screen>
- </informalexample>
+
<para>To get a stack trace, use:</para>
- <informalexample>
+
<screen><userinput>trace</userinput></screen>
- </informalexample>
+
<note>
<para>Note that when entering DDB via a hot-key, the kernel is
@@ -380,32 +380,32 @@ options DDB</programlisting> to your config file, and rebuild. (See <link
<para>If you want to remove a breakpoint, use</para>
- <informalexample>
+
<screen><userinput>del</userinput>
<userinput>del address-expression</userinput></screen>
- </informalexample>
+
<para>The first form will be accepted immediately after
a breakpoint hit, and deletes the current breakpoint. The second
form can remove any breakpoint, but you need to specify the exact
address; this can be obtained from:</para>
- <informalexample>
+
<screen><userinput>show b</userinput></screen>
- </informalexample>
+
<para>To single-step the kernel, try:</para>
- <informalexample>
+
<screen><userinput>s</userinput></screen>
- </informalexample>
+
<para>This will step into functions, but you can make
DDB trace them until the matching return statement is reached by:</para>
- <informalexample>
+
<screen><userinput>n</userinput></screen>
- </informalexample>
+
<note>
<para>This is different from <command>gdb</command>'s <command>next</command>
@@ -414,27 +414,27 @@ options DDB</programlisting> to your config file, and rebuild. (See <link
<para>To examine data from memory, use (for example):
- <informalexample>
+
<screen><userinput>x/wx 0xf0133fe0,40</userinput>
<userinput>x/hd db_symtab_space</userinput>
<userinput>x/bc termbuf,10</userinput>
<userinput>x/s stringbuf</userinput></screen>
- </informalexample>
+
for word/halfword/byte access, and
hexadecimal/decimal/character/ string display. The number after the
comma is the object count. To display the next 0x10 items, simply
use:</para>
- <informalexample>
+
<screen><userinput>x ,10</userinput></screen>
- </informalexample>
+
<para>Similarly, use
- <informalexample>
+
<screen><userinput>x/ia foofunc,10</userinput></screen>
- </informalexample>
+
to disassemble the first 0x10 instructions of
<function>foofunc</function>, and display them along with
@@ -442,10 +442,10 @@ options DDB</programlisting> to your config file, and rebuild. (See <link
<para>To modify memory, use the write command:</para>
- <informalexample>
+
<screen><userinput>w/b termbuf 0xa 0xb 0</userinput>
<userinput>w/w 0xf0010030 0 0</userinput></screen>
- </informalexample>
+
<para>The command modifier
(<literal>b</literal>/<literal>h</literal>/<literal>w</literal>) specifies the size of the data to be
@@ -455,36 +455,36 @@ options DDB</programlisting> to your config file, and rebuild. (See <link
<para>If you need to know the current registers, use:</para>
- <informalexample>
+
<screen><userinput>show reg</userinput></screen>
- </informalexample>
+
<para>Alternatively, you can display a single register
value by e.g.
- <informalexample>
+
<screen><userinput>p $eax</userinput></screen>
- </informalexample> and modify it by:</para>
+ and modify it by:</para>
- <informalexample>
+
<screen><userinput>set $eax new-value</userinput></screen>
- </informalexample>
+
<para>Should you need to call some kernel functions from DDB, simply
say:</para>
- <informalexample>
+
<screen><userinput>call func(arg1, arg2, ...)</userinput></screen>
- </informalexample>
+
<para>The return value will be printed.</para>
<para>For a <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> style summary of all running
processes, use:</para>
- <informalexample>
+
<screen><userinput>ps</userinput></screen>
- </informalexample>
+
<para>Now you have now examined why your kernel failed, and you wish
to reboot. Remember that, depending on the severity of previous
@@ -492,18 +492,18 @@ options DDB</programlisting> to your config file, and rebuild. (See <link
as expected. Perform one of the following actions to shut down and
reboot your system:</para>
- <informalexample>
+
<screen><userinput>call diediedie()</userinput></screen>
- </informalexample>
+
<para>This will cause your kernel to dump core and reboot, so you can
later analyze the core on a higher level with kgdb. This command
usually must be followed by another <command>continue</command> statement. There is now an alias for
this: <command>panic</command>.</para>
- <informalexample>
+
<screen><userinput>call boot(0)</userinput></screen>
- </informalexample>
+
<para>Which might be a good way to cleanly shut down the
running system, <function>sync()</function> all disks, and finally
@@ -511,18 +511,18 @@ options DDB</programlisting> to your config file, and rebuild. (See <link
kernel are not damaged, this might be a good way for an almost clean
shutdown.</para>
- <informalexample>
+
<screen><userinput>call cpu_reset()</userinput></screen>
- </informalexample>
+
<para>is the final way out of disaster and almost the
same as hitting the Big Red Button.</para>
<para>If you need a short command summary, simply type:</para>
- <informalexample>
+
<screen><userinput>help</userinput></screen>
- </informalexample>
+
<para>However, it is highly recommended to have a
printed copy of the <citerefentry><refentrytitle>ddb</refentrytitle><manvolnum>4</manvolnum></citerefentry> manual page
@@ -556,7 +556,7 @@ options DDB</programlisting> to your config file, and rebuild. (See <link
serial line of the debugging host. Now, on the debugging machine,
go to the compile directory of the target kernel, and start gdb:</para>
- <informalexample>
+
<screen>&prompt.user; <userinput>gdb -k kernel</userinput>
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
@@ -564,41 +564,41 @@ There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
<prompt>(kgdb)</prompt> </screen>
- </informalexample>
+
<para>Initialize the remote debugging session (assuming the first
serial port is being used) by:</para>
- <informalexample>
+
<screen><prompt>(kgdb)</prompt> <userinput>target remote /dev/cuaa0</userinput></screen>
- </informalexample>
+
<para>Now, on the target host (the one that entered DDB right before
even starting the device probe), type:</para>
- <informalexample>
+
<screen>Debugger("Boot flags requested debugger")
Stopped at Debugger+0x35: movb $0, edata+0x51bc
<prompt>db&gt;</prompt> <userinput>gdb</userinput></screen>
- </informalexample>
+
<para>DDB will respond with:</para>
- <informalexample>
+
<screen>Next trap will enter GDB remote protocol mode</screen>
- </informalexample>
+
<para>Every time you type <command>gdb</command>, the mode will be toggled between
remote GDB and local DDB. In order to force a next trap
immediately, simply type <command>s</command> (step). Your hosting GDB will now
gain control over the target kernel:</para>
- <informalexample>
+
<screen>Remote debugging using /dev/cuaa0
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
at ../../i386/i386/db_interface.c:257
<prompt>(kgdb)</prompt></screen>
- </informalexample>
+
<para>You can use this session almost as any other GDB session,
including full access to the source, running it in gud-mode inside
@@ -608,33 +608,33 @@ Debugger (msg=0xf01b0383 "Boot flags requested debugger")
<para>Remote GDB can also be used to debug LKMs. First build the LKM
with debugging symbols:</para>
- <informalexample>
+
<screen>&prompt.root; <userinput>cd /usr/src/lkm/linux</userinput>
&prompt.root; <userinput>make clean; make COPTS=-g</userinput></screen>
- </informalexample>
+
<para>Then install this version of the module on the target machine,
load it and use <command>modstat</command> to find out
where it was loaded:</para>
- <informalexample>
+
<screen>&prompt.root; <userinput>linux</userinput>
&prompt.root; <userinput>modstat</userinput>
Type Id Off Loadaddr Size Info Rev Module Name
EXEC 0 4 f5109000 001c f510f010 1 linux_mod</screen>
- </informalexample>
+
<para>Take the load address of the module and add 0x20 (probably to
account for the a.out header). This is the address that the module
code was relocated to. Use the <command>add-symbol-file</command> command in GDB to tell the
debugger about the module:</para>
- <informalexample>
+
<screen><prompt>(kgdb)</prompt> <userinput>add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020</userinput>
add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at
text_addr = 0xf5109020? (y or n) <userinput>y</userinput>
<prompt>(kgdb)</prompt></screen>
- </informalexample>
+
<para>You now have access to all the symbols in the LKM.</para>