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 c9d8425f50..c5b08f3102 100644 --- a/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml +++ b/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml @@ -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->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>