89 lines
		
	
	
		
			3.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			89 lines
		
	
	
		
			3.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
 | 
						|
<sect1 id="gdb"><title>Debugging Cygwin Programs</title>
 | 
						|
 | 
						|
<para>When your program doesn't work right, it usually has a "bug" in
 | 
						|
it, meaning there's something wrong with the program itself that is
 | 
						|
causing unexpected results or crashes.  Diagnosing these bugs and
 | 
						|
fixing them is made easy by special tools called
 | 
						|
<emphasis>debuggers</emphasis>.  In the case of Cygwin, the debugger
 | 
						|
is GDB, which stands for "GNU DeBugger".  This tool lets you run your
 | 
						|
program in a controlled environment where you can investigate the
 | 
						|
state of your program while it is running or after it crashes.
 | 
						|
Crashing programs sometimes create "core" files. In Cygwin these are 
 | 
						|
regular text files that cannot be used directly by GDB.
 | 
						|
</para>
 | 
						|
 | 
						|
<para>Before you can debug your program, you need to prepare your
 | 
						|
program for debugging.  What you need to do is add
 | 
						|
<literal>-g</literal> to all the other flags you use when compiling
 | 
						|
your sources to objects.</para>
 | 
						|
 | 
						|
<example id="gdb-g"><title>Compiling with -g</title>
 | 
						|
<screen>
 | 
						|
<prompt>$</prompt> gcc -g -O2 -c myapp.c
 | 
						|
<prompt>$</prompt> gcc -g myapp.c -o myapp
 | 
						|
</screen>
 | 
						|
</example>
 | 
						|
 | 
						|
<para>What this does is add extra information to the objects (they get
 | 
						|
much bigger too) that tell the debugger about line numbers, variable
 | 
						|
names, and other useful things.  These extra symbols and debugging
 | 
						|
information give your program enough information about the original
 | 
						|
sources so that the debugger can make debugging much easier for
 | 
						|
you.</para>
 | 
						|
 | 
						|
<para>In Windows versions of GNUPro, GDB comes with a full-featured
 | 
						|
graphical interface.  In Cygwin Net distributions, GDB is only
 | 
						|
available as a command-line tool.  To invoke GDB, simply type
 | 
						|
<command>gdb myapp.exe</command> at the command prompt.  It will
 | 
						|
display some text telling you about itself, then
 | 
						|
<literal>(gdb)</literal> will appear to prompt you to enter commands.
 | 
						|
Whenever you see this prompt, it means that gdb is waiting for you to
 | 
						|
type in a command, like <command>run</command> or
 | 
						|
<command>help</command>.  Oh <literal>:-)</literal> type
 | 
						|
<command>help</command> to get help on the commands you can type in,
 | 
						|
or read the <citation>GDB User's Manual</citation> for a complete
 | 
						|
description of GDB and how to use it.</para>
 | 
						|
 | 
						|
<para>If your program crashes and you're trying to figure out why it
 | 
						|
crashed, the best thing to do is type <command>run</command> and let
 | 
						|
your program run.  After it crashes, you can type
 | 
						|
<command>where</command> to find out where it crashed, or
 | 
						|
<command>info locals</command> to see the values of all the local
 | 
						|
variables.  There's also a <command>print</command> that lets you look
 | 
						|
at individual variables or what pointers point to.</para>
 | 
						|
 | 
						|
<para>If your program is doing something unexpected, you can use the
 | 
						|
<command>break</command> command to tell gdb to stop your program when it
 | 
						|
gets to a specific function or line number:</para>
 | 
						|
 | 
						|
<example id="gdb-break"><title>"break" in gdb</title>
 | 
						|
<screen>
 | 
						|
<prompt>(gdb)</prompt> break my_function
 | 
						|
<prompt>(gdb)</prompt> break 47
 | 
						|
</screen>
 | 
						|
</example>
 | 
						|
 | 
						|
<para>Now, when you type <command>run</command> your program will stop
 | 
						|
at that "breakpoint" and you can use the other gdb commands to look at
 | 
						|
the state of your program at that point, modify variables, and
 | 
						|
<command>step</command> through your program's statements one at a
 | 
						|
time.</para>
 | 
						|
 | 
						|
<para>Note that you may specify additional arguments to the
 | 
						|
<command>run</command> command to provide command-line arguments to
 | 
						|
your program.  These two cases are the same as far as your program is
 | 
						|
concerned:</para>
 | 
						|
 | 
						|
<example id="gdb-cliargs"><title>Debugging with command line arguments</title>
 | 
						|
<screen>
 | 
						|
<prompt>$</prompt> myprog -t foo --queue 47
 | 
						|
 | 
						|
<prompt>$</prompt> gdb myprog
 | 
						|
<prompt>(gdb)</prompt> run -t foo --queue 47
 | 
						|
</screen>
 | 
						|
</example>
 | 
						|
 | 
						|
 | 
						|
</sect1>
 |