os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Remove two sections about kerneldebugging (post mortem analysis and

Browse source 
loadable modules using gdb) because the steps described in them are
not necessary anymore for quite a long time.

A rewrite would be in order, but since this goes beyond the scope of
the PR, I'll just remove them for now.

PR:             docs/143342
Submitted by:   trasz@
Reviewed by:    jhb@ via trasz@
This commit is contained in:
Benedict Reuschling 2010-09-19 18:15:03 +00:00
parent c6c8bac49b
commit 9c4c826a5f
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=36432
1 changed files with 0 additions and 97 deletions

97
en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
View file

@ -442,44 +442,6 @@
<command>ddd</command>'s graphical interface.</para>
</sect1>
<sect1 id="kerneldebug-post-mortem">
<title>Post-Mortem Analysis of a Dump</title>
<para>What do you do if a kernel dumped core but you did not expect it,
and it is therefore not compiled using <command>config -g</command>? Not
everything is lost here. Do not panic!</para>
<para>Of course, you still need to enable crash dumps. See above for the
options you have to specify in order to do this.</para>
<para>Go to your kernel config directory
(<filename>/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>)
and edit your configuration file. Uncomment (or add, if it does not
exist) the following line:</para>
<programlisting>makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols</programlisting>
<para>Rebuild the kernel. Due to the time stamp change on the Makefile,
some other object files will be rebuilt, for example
<filename>trap.o</filename>. With a bit of luck, the added
<option>-g</option> option will not change anything for the generated
code, so you will finally get a new kernel with similar code to the
faulting one but with some debugging symbols. You should at least verify the
old and new sizes with the &man.size.1; command. If there is a
mismatch, you probably need to give up here.</para>
<para>Go and examine the dump as described above. The debugging symbols
might be incomplete for some places, as can be seen in the stack trace
in the example above where some functions are displayed without line
numbers and argument lists. If you need more debugging symbols, remove
the appropriate object files, recompile the kernel again and repeat the
<command>gdb <option>-k</option></command>
session until you know enough.</para>
<para>All this is not guaranteed to work, but it will do it fine in most
cases.</para>
</sect1>
<sect1 id="kerneldebug-online-ddb">
<title>On-Line Kernel Debugging Using DDB</title>
@ -769,65 +731,6 @@ Debugger (msg=0xf01b0383 "Boot flags requested debugger")
window), etc.</para>
</sect1>
<sect1 id="kerneldebug-kld">
<title>Debugging Loadable Modules Using GDB</title>
<para>When debugging a panic that occurred within a module, or
using remote GDB against a machine that uses dynamic modules,
you need to tell GDB how to obtain symbol information for those
modules.</para>
<para>First, you need to build the module(s) with debugging
information:</para>
<screen>&prompt.root; <userinput>cd /sys/modules/linux</userinput>
&prompt.root; <userinput>make clean; make COPTS=-g</userinput></screen>
<para>If you are using remote GDB, you can run
<command>kldstat</command> on the target machine to find out
where the module was loaded:</para>
<screen>&prompt.root; <userinput>kldstat</userinput>
Id Refs Address Size Name
1 4 0xc0100000 1c1678 kernel
2 1 0xc0a9e000 6000 linprocfs.ko
3 1 0xc0ad7000 2000 warp_saver.ko
4 1 0xc0adc000 11000 linux.ko</screen>
<para>If you are debugging a crash dump, you will need to walk the
<literal>linker_files</literal> list, starting at
<literal>linker_files-&gt;tqh_first</literal> and following the
<literal>link.tqe_next</literal> pointers until you find the
entry with the <literal>filename</literal> you are looking for.
The <literal>address</literal> member of that entry is the load
address of the module.</para>
<para>Next, you need to find out the offset of the text section
within the module:</para>
<screen>&prompt.root; <userinput>objdump --section-headers /sys/modules/linux/linux.ko | grep text</userinput>
3 .rel.text 000016e0 000038e0 000038e0 000038e0 2**2
10 .text 00007f34 000062d0 000062d0 000062d0 2**2</screen>
<para>The one you want is the <literal>.text</literal> section,
section 10 in the above example. The fourth hexadecimal field
(sixth field overall) is the offset of the text section within
the file. Add this offset to the load address of the module to
obtain the relocation address for the module's code. In our
example, we get 0xc0adc000 + 0x62d0 = 0xc0ae22d0. Use the
<command>add-symbol-file</command> command in GDB to tell the
debugger about the module:</para>
<screen><prompt>(kgdb)</prompt> <userinput>add-symbol-file /sys/modules/linux/linux.ko 0xc0ae22d0</userinput>
add symbol table from file "/sys/modules/linux/linux.ko" at text_addr = 0xc0ae22d0?
(y or n) <userinput>y</userinput>
Reading symbols from /sys/modules/linux/linux.ko...done.
<prompt>(kgdb)</prompt></screen>
<para>You should now have access to all the symbols in the
module.</para>
</sect1>
<sect1 id="kerneldebug-console">
<title>Debugging a Console Driver</title>