[gentoo-doc-cvs] cvs commit: debugging-howto.xml

[gentoo-doc-cvs] cvs commit: debugging-howto.xml

[Sven Vermeulen]

swift       05/07/14 09:42:27

  Modified:    xml/htdocs/doc/en/draft debugging-howto.xml
  Log:
  Coding Style

Revision  Changes    Path
1.3       +27 -26    xml/htdocs/doc/en/draft/debugging-howto.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.3&content-type=text/plain&cvsroot=gentoo
diff : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml.diff?r1=1.2&r2=1.3&cvsroot=gentoo

Index: debugging-howto.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- debugging-howto.xml	13 Jul 2005 18:58:31 -0000	1.2
+++ debugging-howto.xml	14 Jul 2005 09:42:27 -0000	1.3
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.2 2005/07/13 18:58:31 fox2mike Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.3 2005/07/14 09:42:27 swift Exp $ -->
 
 <guide link="/doc/en/debugging-howto.xml">
 <title>Gentoo Linux Debugging Guide</title>
@@ -138,8 +138,8 @@
 </pre>
 
 <p>
-Lastly, you can also add debug to the package's USE flags. This can be done with the
-<path>package.use</path> file.
+Lastly, you can also add debug to the package's USE flags. This can be done 
+with the <path>package.use</path> file.
 </p> 
 
 <pre caption="Using package.use to add debug USE flag">
@@ -245,8 +245,8 @@
 run_it(), and somewhere in run_it() lies the strcpy() at fault. Things such as
 this help developers narrow down problems. There are a few exceptions to the
 output. First off is forgetting to enable debug symbols with
-<c>FEATURES="nostrip"</c>. With debug symbols stripped, the output looks something
-like this:
+<c>FEATURES="nostrip"</c>. With debug symbols stripped, the output looks 
+something like this:
 </p>
 
 <pre caption="Program backtrace With debug symbols stripped">
@@ -311,13 +311,14 @@
 </pre>
 
 <p>
-As you can see, -ggdb3 adds about <e>13178</e> more bytes to the file size over the one
-with debugging symbols. However, as shown above, this increase in file size can
-be worth it if presenting debug information to developers. The backtrace can be
-saved to a file by copying and pasting from the terminal (if it's a non-x based
-terminal, you can use gpm. To keep this doc simple, I recommend you read up on
-the documentation for gpm to see how to copy and paste with it). Now that we're
-done with <c>gdb</c>, we can quit.
+As you can see, -ggdb3 adds about <e>13178</e> more bytes to the file size 
+over the one with debugging symbols. However, as shown above, this increase 
+in file size can be worth it if presenting debug information to developers.
+The backtrace can be saved to a file by copying and pasting from the 
+terminal (if it's a non-x based terminal, you can use gpm. To keep this 
+doc simple, I recommend you read up on the documentation for gpm to see
+how to copy and paste with it). Now that we're done with <c>gdb</c>, we 
+can quit.
 </p>
 
 <pre caption="Quitting GDB">
@@ -327,11 +328,11 @@
 </pre>
 
 <p>
-This ends the walk-through of <c>gdb</c>. Using <c>gdb</c>, we hope that you will
-be able to use it to create better bug reports. However, there are other types
-of errors that can cause a program to fail during run time. One of the other
-ways is through improper file access. We can find those using a nifty little
-tool called <c>strace</c>.
+This ends the walk-through of <c>gdb</c>. Using <c>gdb</c>, we hope that you 
+will be able to use it to create better bug reports. However, there are other 
+types of errors that can cause a program to fail during run time. One of the 
+other ways is through improper file access. We can find those using a nifty 
+little tool called <c>strace</c>.
 </p>
 
 </body>
@@ -350,9 +351,9 @@
 tool called <c>strace</c> was created to help deal with this. <c>strace</c>
 traces system calls (hence the name) which include calls that use the memory and
 files. For our example, we're going to take a program foobar2. This is an
-updated version of foobar. However, during the change over to foobar2, you notice
-all your configurations are missing!  In foobar version 1, you had it setup to
-say "foo", but now it's using the default "bar".
+updated version of foobar. However, during the change over to foobar2, you 
+notice all your configurations are missing!  In foobar version 1, you had it 
+setup to say "foo", but now it's using the default "bar".
 </p>
 
 <pre caption="Foobar2 With an invalid configuration">
@@ -406,9 +407,9 @@
 <body>
 
 <p>
-<c>strace</c> is a great way at seeing what the kernel is doing to with the filesystem.
-Another program exists to help users see what the kernel is doing, and help with
-kernel debugging.  This program is called <c>dmesg</c>
+<c>strace</c> is a great way at seeing what the kernel is doing to with the 
+filesystem. Another program exists to help users see what the kernel is doing,
+and help with kernel debugging.  This program is called <c>dmesg</c>.
 </p>
 
 </body>
@@ -569,9 +570,9 @@
 </pre>
 
 <p>
-The program is compiling smoothly when it suddenly stops and presents an error message. This
-particular error can be split into 3 different sections, The compile messages, the build
-error, and the emerge error message as shown below.
+The program is compiling smoothly when it suddenly stops and presents an error 
+message. This particular error can be split into 3 different sections, The 
+compile messages, the build error, and the emerge error message as shown below.
 </p>
 
 <pre caption="Parts of the error">



-- 
gentoo-doc-cvs@gentoo.org mailing list

[gentoo-doc-cvs] cvs commit: debugging-howto.xml

[Shyam Mani]

fox2mike    05/07/14 09:54:37

  Modified:    xml/htdocs/doc/en/draft debugging-howto.xml
  Log:
  Coding Style + Doublespace fixes.

Revision  Changes    Path
1.4       +19 -18    xml/htdocs/doc/en/draft/debugging-howto.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.4&content-type=text/plain&cvsroot=gentoo
diff : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml.diff?r1=1.3&r2=1.4&cvsroot=gentoo

Index: debugging-howto.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- debugging-howto.xml	14 Jul 2005 09:42:27 -0000	1.3
+++ debugging-howto.xml	14 Jul 2005 09:54:37 -0000	1.4
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.3 2005/07/14 09:42:27 swift Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.4 2005/07/14 09:54:37 fox2mike Exp $ -->
 
 <guide link="/doc/en/debugging-howto.xml">
 <title>Gentoo Linux Debugging Guide</title>
@@ -423,9 +423,9 @@
 <body>
 
 <p>
-<c>dmesg</c> is a system program created with debugging kernel operation.  It
+<c>dmesg</c> is a system program created with debugging kernel operation. It
 basically reads the kernel messages and keeps them in buffer, letting the user
-see them later on.  Here's an example of what a dmesg output looks like:
+see them later on. Here's an example of what a dmesg output looks like:
 </p>
 
 <pre caption="dmesg sample output">
@@ -463,12 +463,12 @@
 </pre>
 
 <p>
-The dmesg displayed here is my machine's bootup.  You can see harddrives and
+The dmesg displayed here is my machine's bootup. You can see the hard disks and
 input devices being initialized.  While what you see here seems relatively
-harmless, <c>dmesg</c> is also good at showing when things go wrong.  Let's take
-for example an IPAQ 1945 I have.  After a couple of minutes of inactivity, the
-device powers off.  Now, I have the device connected into the USB port in the
-front of my system.  Now, I want to copy over some files using libsynCE, so I go
+harmless, <c>dmesg</c> is also good at showing when things go wrong. Let's take
+for example an IPAQ 1945 I have. After a couple of minutes of inactivity, the
+device powers off. Now, I have the device connected into the USB port in the
+front of my system. Now, I want to copy over some files using libsynCE, so I go
 ahead and initiate a connection:
 </p>
 
@@ -484,7 +484,7 @@
 The connection fails, as we see here, and we assume that only the screen is in
 powersave mode, and that maybe the connection is faulty.  In order to see what
 truly happened, we can use <c>dmesg</c>.  Now, <c>dmesg</c> tends to give a
-rather large ammount of output.  One can use the <c>tail</c> command to help
+rather large ammount of output. One can use the <c>tail</c> command to help
 keep the output down:
 </p>
 
@@ -497,15 +497,16 @@
 </pre>
 
 <p>
-This gives us the last 4 lines of the dmesg output.  Now, this is enough to give
-us some information on the situation.  It seems that in the first 2 lines, the
-pocketpc is recognized as connected.  However, in the last 2 lines, it appears
-to have been disconnected.  With this information we check the pocketpc again,
-and find out it is powered off, and now know about the powersave mode.  We can
-use this information to turn the feature off, or be aware of it next time.
-While this is a somewhat simple example, it does go to show how well dmesg can
-work.  However, in more complex examples (such as kernel bugs), the entire dmesg
-output may be required.  To obtain that, simple redirect to a log file as such:
+This gives us the last 4 lines of the <c>dmesg</c> output. Now, this is enough
+to give us some information on the situation. It seems that in the first 2
+lines, the pocketpc is recognized as connected. However, in the last 2 lines, it
+appears to have been disconnected. With this information we check the pocketpc
+again, and find out it is powered off, and now know about the powersave mode. We
+can use this information to turn the feature off, or be aware of it next time.
+While this is a somewhat simple example, it does go to show how well
+<c>dmesg</c> can work. However, in more complex examples (such as kernel bugs),
+the entire <c>dmesg</c> output may be required. To obtain that, simple redirect
+to a log file as such:
 </p>
 
 <pre caption="Saving dmesg output to a log">



-- 
gentoo-doc-cvs@gentoo.org mailing list

[gentoo-doc-cvs] cvs commit: debugging-howto.xml

[Shyam Mani]

fox2mike    05/07/13 18:58:31

  Modified:    xml/htdocs/doc/en/draft debugging-howto.xml
  Log:
  dmesh patch from Chris White aka PUNK ;)

Revision  Changes    Path
1.2       +120 -5    xml/htdocs/doc/en/draft/debugging-howto.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.2&content-type=text/plain&cvsroot=gentoo
diff : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml.diff?r1=1.1&r2=1.2&cvsroot=gentoo

Index: debugging-howto.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- debugging-howto.xml	13 Jul 2005 05:55:39 -0000	1.1
+++ debugging-howto.xml	13 Jul 2005 18:58:31 -0000	1.2
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.1 2005/07/13 05:55:39 fox2mike Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.2 2005/07/13 18:58:31 fox2mike Exp $ -->
 
 <guide link="/doc/en/debugging-howto.xml">
 <title>Gentoo Linux Debugging Guide</title>
@@ -406,10 +406,125 @@
 <body>
 
 <p>
-Now we've taken care of finding run time bugs. These bugs prove to be
-problematic when you try and run your programs. However, run time errors are
-the least of your concerns if your program won't compile at all. Let's take a
-look at how to address <c>emerge</c> compile errors.
+<c>strace</c> is a great way at seeing what the kernel is doing to with the filesystem.
+Another program exists to help users see what the kernel is doing, and help with
+kernel debugging.  This program is called <c>dmesg</c>
+</p>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Kernel Debugging With dmesg</title>
+<section>
+<title>dmesg Introduction</title>
+<body>
+
+<p>
+<c>dmesg</c> is a system program created with debugging kernel operation.  It
+basically reads the kernel messages and keeps them in buffer, letting the user
+see them later on.  Here's an example of what a dmesg output looks like:
+</p>
+
+<pre caption="dmesg sample output">
+SIS5513: IDE controller at PCI slot 0000:00:02.5
+SIS5513: chipset revision 208
+SIS5513: not 100% native mode: will probe irqs later
+SIS5513: SiS 961 MuTIOL IDE UDMA100 controller
+ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA
+ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:DMA
+Probing IDE interface ide0...
+input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
+hda: WDC WD800BB-60CJA0, ATA DISK drive
+hdb: CD-RW 52X24, ATAPI CD/DVD-ROM drive
+ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
+Probing IDE interface ide1...
+hdc: SAMSUNG DVD-ROM SD-616T, ATAPI CD/DVD-ROM drive
+hdd: Maxtor 92049U6, ATA DISK drive
+ide1 at 0x170-0x177,0x376 on irq 15
+hda: max request size: 128KiB
+hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63,
+UDMA(100)
+hda: cache flushes not supported
+hda: hda1
+hdd: max request size: 128KiB
+hdd: 39882528 sectors (20419 MB) w/2048KiB Cache, CHS=39566/16/63,
+UDMA(66)
+hdd: cache flushes not supported
+hdd: unknown partition table
+hdb: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
+Uniform CD-ROM driver Revision: 3.20
+hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
+ide-floppy driver 0.99.newide
+libata version 1.11 loaded.
+usbmon: debugs is not available	  
+</pre>
+
+<p>
+The dmesg displayed here is my machine's bootup.  You can see harddrives and
+input devices being initialized.  While what you see here seems relatively
+harmless, <c>dmesg</c> is also good at showing when things go wrong.  Let's take
+for example an IPAQ 1945 I have.  After a couple of minutes of inactivity, the
+device powers off.  Now, I have the device connected into the USB port in the
+front of my system.  Now, I want to copy over some files using libsynCE, so I go
+ahead and initiate a connection:
+</p>
+
+<pre caption="IPAQ connection attempt">
+# <i>synce-serial-start</i>
+/usr/sbin/pppd: In file /etc/ppp/peers/synce-device: unrecognized option
+'/dev/tts/USB0'
+
+synce-serial-start was unable to start the PPP daemon!
+</pre>
+
+<p>
+The connection fails, as we see here, and we assume that only the screen is in
+powersave mode, and that maybe the connection is faulty.  In order to see what
+truly happened, we can use <c>dmesg</c>.  Now, <c>dmesg</c> tends to give a
+rather large ammount of output.  One can use the <c>tail</c> command to help
+keep the output down:
+</p>
+
+<pre caption="Adjusting the output ammount with tail">
+$ <i>dmesg | tail -n 4</i>
+usb 1-1.2: PocketPC PDA converter now attached to ttyUSB0
+usb 1-1.2: USB disconnect, address 11
+PocketPC PDA ttyUSB0: PocketPC PDA converter now disconnected from ttyUSB0
+ipaq 1-1.2:1.0: device disconnected
+</pre>
+
+<p>
+This gives us the last 4 lines of the dmesg output.  Now, this is enough to give
+us some information on the situation.  It seems that in the first 2 lines, the
+pocketpc is recognized as connected.  However, in the last 2 lines, it appears
+to have been disconnected.  With this information we check the pocketpc again,
+and find out it is powered off, and now know about the powersave mode.  We can
+use this information to turn the feature off, or be aware of it next time.
+While this is a somewhat simple example, it does go to show how well dmesg can
+work.  However, in more complex examples (such as kernel bugs), the entire dmesg
+output may be required.  To obtain that, simple redirect to a log file as such:
+</p>
+
+<pre caption="Saving dmesg output to a log">
+$ <i>dmesg > dmesg.log</i>
+</pre>
+
+<p>
+You can then attach this to a bug report, or post it online somewhere for
+collaborative debugging sessions.
+</p>
+
+</body>
+</section>
+<section>
+<title>Conclusion</title>
+<body>
+
+<p>
+Now that we've taken a look at a few ways to debug runtime and kernel errors,
+let's take a look at how to handle emerge errors.
 </p>
 
 </body>



-- 
gentoo-doc-cvs@gentoo.org mailing list

[gentoo-doc-cvs] cvs commit: debugging-howto.xml

[Shyam Mani]

fox2mike    05/07/13 05:55:39

  Added:       xml/htdocs/doc/en/draft debugging-howto.xml
  Log:
  Initial Version of the debugging-guide, originally part of the bugzilla-howto.

Revision  Changes    Path
1.1                  xml/htdocs/doc/en/draft/debugging-howto.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/debugging-howto.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: debugging-howto.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/debugging-howto.xml,v 1.1 2005/07/13 05:55:39 fox2mike Exp $ -->

<guide link="/doc/en/debugging-howto.xml">
<title>Gentoo Linux Debugging Guide</title>

<author title="Author">
  <mail link="chriswhite@gentoo.org">Chris White</mail>
</author>
<author title="Editor">
  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
</author>

<abstract>
This document aims at helping the user debug various errors they may encounter
during day to day usage of Gentoo.
</abstract>

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>

<version>1.0</version>
<date>2005-07-13</date>

<chapter>
<title>Introduction</title>
<section>
<title>Preface</title>
<body>

<p>
One of the factors that delay a bug being fixed is the way it is reported. By
creating this guide, we hope to help improve the communication between
developers and users in bug resolution. Getting bugs fixed is an important, if
not crucial part of the quality assurance for any project and hopefully this
guide will help make that a success.
</p>

</body>
</section>
<section>
<title>Bugs!!!!</title>
<body>

<p>
You're emerge-ing a package or working with a program and suddenly the worst
happens -- you find a bug. Bugs come in many forms like emerge failures or
segmentation faults. Whatever the cause, the fact still remains that such a bug
must be fixed. Here is a few examples of such bugs.
</p>

<pre caption="A run time error">
$ <i>./bad_code `perl -e 'print Ax100'`</i>
Segmentation fault
</pre>

<pre caption="An emerge failure">
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the &lt;X&gt; header for the &lt;X.h&gt;
header for C++ includes, or &lt;sstream&gt; instead of the deprecated header
&lt;strstream.h&gt;. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2

!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed
</pre>

<p>
These errors can be quite troublesome. However, once you find them, what do
you do? The following sections will look at two important tools for handling
run time errors. After that, we'll take a look at compile errors, and how to
handle them. Let's start out with the first tool for debugging run time 
errors -- <c>gdb</c>.
</p>

</body>
</section>
</chapter>


<chapter>
<title>Debugging using GDB</title>
<section>
<title>Introduction</title>
<body>

<p>
GDB, or the (G)NU (D)e(B)ugger, is a program used to find run time errors that
normally involve memory corruption. First off, let's take a look at what
debugging entails. One of the main things you must do in order to debug a
program is to <c>emerge</c> the program with <c>FEATURES="nostrip"</c>. This
prevents the stripping of debug symbols. Why are programs stripped by default?
The reason is the same as that for having gzipped man pages -- saving space.
Here's how the size of a program varies with and without debug symbol stripping. 
</p>

<pre caption="Filesize Comparison">
<comment>(debug symbols stripped)</comment>
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
<comment>(debug symbols intact)</comment>
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
</pre>

<p>
Just for reference, <e>bad_code</e> is the program we'll be debugging with
<c>gdb</c> later on. As you can see, the program without debugging symbols is
3140 bytes, while the program with them is 6374 bytes. That's close to double
the size! Two more things can be done for debugging. The first is adding ggdb3
to your CFLAGS and CXXFLAGS. This flag adds more debugging information than is
generally included. We'll see what that means later on. This is how
<path>/etc/make.conf</path> <e>might</e> look with the newly added flags.  
</p>

<pre caption="make.conf settings">
CFLAGS="-O2 -pipe -ggdb3"
CXXFLAGS="${CFLAGS}"
</pre>

<p>
Lastly, you can also add debug to the package's USE flags. This can be done with the
<path>package.use</path> file.
</p> 

<pre caption="Using package.use to add debug USE flag">
# <i>echo "category/package debug" >> /etc/portage/package.use</i>
</pre>

<note>
The directory <path>/etc/portage</path> does not exist by default and you may
have to create it, if you have not already done so. If the package already has
USE flags set in <path>package.use</path>, you will need to manually modify them
in your favorite editor.
</note>

<p>
Then we re-emerge the package with the modifications we've done so far as shown
below.
</p>

<pre caption="Re-emergeing a package with debugging">
# <i>FEATURES="nostrip" emerge package</i>
</pre>

<p>
Now that debug symbols are setup, we can continue with debugging the program.
</p>

</body>
</section>
<section>
<title>Running the program with GDB</title>
<body>

<p>
Let's say we have a program here called "bad_code". Some person claims that the
program crashes and provides an example. You go ahead and test it out:
</p>

<pre caption="Breaking The Program">
$ <i>./bad_code `perl -e 'print Ax100'`</i>
Segmentation fault
</pre>

<p>
It seems this person was right. Since the program is obviously broken, we have
a bug at hand. Now, it's time to use <c>gdb</c> to help solve this matter. First
we run <c>gdb</c> with <c>--args</c>, then give it the full program with
arguments like shown:
</p>

<pre caption="Running Our Program Through GDB">
$ <i>gdb --args ./bad_code `perl -e 'print Ax100'`</i>
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.



-- 
gentoo-doc-cvs@gentoo.org mailing list