diff options
author | Nik Clayton <nik@FreeBSD.org> | 1999-01-30 23:35:05 +0000 |
---|---|---|
committer | Nik Clayton <nik@FreeBSD.org> | 1999-01-30 23:35:05 +0000 |
commit | 7321b94099016efbe3b05e82b2ed7d908e84cd99 (patch) | |
tree | 75507fdab8310f4a663cc66b24c28592f3dea9ae /en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml | |
parent | 84b6327dc093291e25fb79dfb80cb75f0543f697 (diff) | |
download | doc-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.sgml | 128 |
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></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> |