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

Update information on how to build a debug kernel, fix a typo and

Browse source 
a contraction.

PR:             docs/11849
Submitted by:   chris@calldei.com
This commit is contained in:
Nik Clayton 1999-05-29 12:55:39 +00:00
parent c1762b1b9b
commit 419cffe7ba
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=4966
4 changed files with 68 additions and 64 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
en/handbook/kerneldebug/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$Id: chapter.sgml,v 1.14 1999-05-22 16:36:02 obrien Exp $
$Id: chapter.sgml,v 1.15 1999-05-29 12:55:39 nik Exp $
-->
<chapter id="kerneldebug">
@ -242,7 +242,7 @@
<screen>&prompt.root; <userinput>ddd -k /var/crash/kernel.0 /var/crash/vmcore.0</userinput></screen>
<para>You should then be able to go about looking at the crash dump using
<command>ddd</command>'d graphical interface.</para>
<command>ddd</command>'s graphical interface.</para>
</sect1>
<sect1>
@ -254,22 +254,23 @@
<para>Of course, you still need to enable crash dumps. See above on the
options you have to specify in order to do this.</para>
<para>Go to your kernel compile directory, and edit the line containing
<literal>COPTFLAGS?=-O</literal>. Add the <option>-g</option> option
there (but <emphasis>do not</emphasis> change anything on the level of
optimization). If you do already know roughly the probable location of
the failing piece of code (e.g., the <devicename>pcvt</devicename>
driver in the example above), remove all the object files for this code.
Rebuild the kernel. Due to the time stamp change on the Makefile, there
will be some other object files rebuild, for example
<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,
there will be some other object files rebuild, 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 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>
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
@ -481,8 +482,8 @@ options DDB</programlisting>
<sect1>
<title>On-line Kernel Debugging Using Remote GDB</title>
<para>This feature has been supported since FreeBSD 2.2, and it's actually
a very neat one.</para>
<para>This feature has been supported since FreeBSD 2.2, and it is
actually a very neat one.</para>
<para>GDB has already supported <emphasis>remote debugging</emphasis> for
a long time. This is done using a very simple protocol along a serial

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

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$Id: chapter.sgml,v 1.14 1999-05-22 16:36:02 obrien Exp $
$Id: chapter.sgml,v 1.15 1999-05-29 12:55:39 nik Exp $
-->
<chapter id="kerneldebug">
@ -242,7 +242,7 @@
<screen>&prompt.root; <userinput>ddd -k /var/crash/kernel.0 /var/crash/vmcore.0</userinput></screen>
<para>You should then be able to go about looking at the crash dump using
<command>ddd</command>'d graphical interface.</para>
<command>ddd</command>'s graphical interface.</para>
</sect1>
<sect1>
@ -254,22 +254,23 @@
<para>Of course, you still need to enable crash dumps. See above on the
options you have to specify in order to do this.</para>
<para>Go to your kernel compile directory, and edit the line containing
<literal>COPTFLAGS?=-O</literal>. Add the <option>-g</option> option
there (but <emphasis>do not</emphasis> change anything on the level of
optimization). If you do already know roughly the probable location of
the failing piece of code (e.g., the <devicename>pcvt</devicename>
driver in the example above), remove all the object files for this code.
Rebuild the kernel. Due to the time stamp change on the Makefile, there
will be some other object files rebuild, for example
<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,
there will be some other object files rebuild, 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 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>
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
@ -481,8 +482,8 @@ options DDB</programlisting>
<sect1>
<title>On-line Kernel Debugging Using Remote GDB</title>
<para>This feature has been supported since FreeBSD 2.2, and it's actually
a very neat one.</para>
<para>This feature has been supported since FreeBSD 2.2, and it is
actually a very neat one.</para>
<para>GDB has already supported <emphasis>remote debugging</emphasis> for
a long time. This is done using a very simple protocol along a serial

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

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$Id: chapter.sgml,v 1.14 1999-05-22 16:36:02 obrien Exp $
$Id: chapter.sgml,v 1.15 1999-05-29 12:55:39 nik Exp $
-->
<chapter id="kerneldebug">
@ -242,7 +242,7 @@
<screen>&prompt.root; <userinput>ddd -k /var/crash/kernel.0 /var/crash/vmcore.0</userinput></screen>
<para>You should then be able to go about looking at the crash dump using
<command>ddd</command>'d graphical interface.</para>
<command>ddd</command>'s graphical interface.</para>
</sect1>
<sect1>
@ -254,22 +254,23 @@
<para>Of course, you still need to enable crash dumps. See above on the
options you have to specify in order to do this.</para>
<para>Go to your kernel compile directory, and edit the line containing
<literal>COPTFLAGS?=-O</literal>. Add the <option>-g</option> option
there (but <emphasis>do not</emphasis> change anything on the level of
optimization). If you do already know roughly the probable location of
the failing piece of code (e.g., the <devicename>pcvt</devicename>
driver in the example above), remove all the object files for this code.
Rebuild the kernel. Due to the time stamp change on the Makefile, there
will be some other object files rebuild, for example
<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,
there will be some other object files rebuild, 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 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>
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
@ -481,8 +482,8 @@ options DDB</programlisting>
<sect1>
<title>On-line Kernel Debugging Using Remote GDB</title>
<para>This feature has been supported since FreeBSD 2.2, and it's actually
a very neat one.</para>
<para>This feature has been supported since FreeBSD 2.2, and it is
actually a very neat one.</para>
<para>GDB has already supported <emphasis>remote debugging</emphasis> for
a long time. This is done using a very simple protocol along a serial

33
en_US.ISO_8859-1/books/handbook/kerneldebug/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$Id: chapter.sgml,v 1.14 1999-05-22 16:36:02 obrien Exp $
$Id: chapter.sgml,v 1.15 1999-05-29 12:55:39 nik Exp $
-->
<chapter id="kerneldebug">
@ -242,7 +242,7 @@
<screen>&prompt.root; <userinput>ddd -k /var/crash/kernel.0 /var/crash/vmcore.0</userinput></screen>
<para>You should then be able to go about looking at the crash dump using
<command>ddd</command>'d graphical interface.</para>
<command>ddd</command>'s graphical interface.</para>
</sect1>
<sect1>
@ -254,22 +254,23 @@
<para>Of course, you still need to enable crash dumps. See above on the
options you have to specify in order to do this.</para>
<para>Go to your kernel compile directory, and edit the line containing
<literal>COPTFLAGS?=-O</literal>. Add the <option>-g</option> option
there (but <emphasis>do not</emphasis> change anything on the level of
optimization). If you do already know roughly the probable location of
the failing piece of code (e.g., the <devicename>pcvt</devicename>
driver in the example above), remove all the object files for this code.
Rebuild the kernel. Due to the time stamp change on the Makefile, there
will be some other object files rebuild, for example
<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,
there will be some other object files rebuild, 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 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>
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
@ -481,8 +482,8 @@ options DDB</programlisting>
<sect1>
<title>On-line Kernel Debugging Using Remote GDB</title>
<para>This feature has been supported since FreeBSD 2.2, and it's actually
a very neat one.</para>
<para>This feature has been supported since FreeBSD 2.2, and it is
actually a very neat one.</para>
<para>GDB has already supported <emphasis>remote debugging</emphasis> for
a long time. This is done using a very simple protocol along a serial