Source string Read only

(itstool) path: sect3/para
217/2170
Context English State
Start up gdb by typing
<prompt>%</prompt> <userinput>gdb <replaceable>progname</replaceable></userinput>
although many people prefer to run it inside <application>Emacs</application>. To do this, type:
<userinput>M-x gdb RET <replaceable>progname</replaceable> RET</userinput>
Finally, for those finding its text-based command-prompt style off-putting, there is a graphical front-end for it (<package>devel/xxgdb</package>) in the Ports Collection.
Running a Program with gdb
Compile the program with <option>-g</option> to get the most out of using <command>gdb</command>. It will work without, but will only display the name of the function currently running, instead of the source code. A line like:
… (no debugging symbols found) …
when <command>gdb</command> starts up means that the program was not compiled with <option>-g</option>.
At the <command>gdb</command> prompt, type <userinput>break main</userinput>. This will tell the debugger to skip the preliminary set-up code in the program being run and to stop execution at the beginning of the program's code. Now type <userinput>run</userinput> to start the program— it will start at the beginning of the set-up code and then get stopped by the debugger when it calls <function>main()</function>.
To step through the program a line at a time, press <command>n</command>. When at a function call, step into it by pressing <command>s</command>. Once in a function call, return from it by pressing <command>f</command>, or use <command>up</command> and <command>down</command> to take a quick look at the caller.
Here is a simple example of how to spot a mistake in a program with <command>gdb</command>. This is our program (with a deliberate mistake):
<prompt>%</prompt> <userinput>cc -g -o temp temp.c</userinput>
<prompt>%</prompt> <userinput>./temp</userinput>
This is my program
anint = 4231
That was not what we expected! Time to see what is going on!
<prompt>%</prompt> <userinput>gdb temp</userinput>
GDB is free software and you are welcome to 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.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) <userinput>break main</userinput> <lineannotation>Skip the set-up code</lineannotation>
Breakpoint 1 at 0x160f: file temp.c, line 9. <lineannotation>gdb puts breakpoint at main()</lineannotation>
(gdb) <userinput>run</userinput> <lineannotation>Run as far as main()</lineannotation>
Starting program: /home/james/tmp/temp <lineannotation>Program starts running</lineannotation>

Breakpoint 1, main () at temp.c:9 <lineannotation>gdb stops at main()</lineannotation>
(gdb) <userinput>n</userinput> <lineannotation>Go to next line</lineannotation>
This is my program <lineannotation>Program prints out</lineannotation>
(gdb) <userinput>s</userinput> <lineannotation>step into bazz()</lineannotation>
bazz (anint=4231) at temp.c:17 <lineannotation>gdb displays stack frame</lineannotation>
(gdb)
Hang on a minute! How did <symbol>anint</symbol> get to be <literal>4231</literal>? Was it not set to <literal>5</literal> in <function>main()</function>? Let us move up to <function>main()</function> and have a look.
(gdb) <userinput>up</userinput> <lineannotation>Move up call stack</lineannotation>
#1 0x1625 in main () at temp.c:11 <lineannotation>gdb displays stack frame</lineannotation>
(gdb) <userinput>p i</userinput> <lineannotation>Show us the value of i</lineannotation>
$1 = 4231 <lineannotation>gdb displays 4231</lineannotation>
but we left the <literal>i=5;</literal> line out. As we did not initialize <symbol>i</symbol>, it had whatever number happened to be in that area of memory when the program ran, which in this case happened to be <literal>4231</literal>.
The <command>gdb</command> command displays the stack frame every time we go into or out of a function, even if we are using <command>up</command> and <command>down</command> to move around the call stack. This shows the name of the function and the values of its arguments, which helps us keep track of where we are and what is going on. (The stack is a storage area where the program stores information about the arguments passed to functions and where to go when it returns from a function call.)
Examining a Core File with gdb
To examine a core file, start up <command>gdb</command> in the usual way. Instead of typing <command>break</command> or <command>run</command>, type
(gdb) <userinput>core <replaceable>progname</replaceable>.core</userinput>
If the core file is not in the current directory, type <userinput>dir /path/to/core/file</userinput> first.
The debugger should display something like this:
<prompt>%</prompt> <userinput>gdb <filename><replaceable>progname</replaceable></filename></userinput>
GDB is free software and you are welcome to 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.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) <userinput>core <filename><replaceable>progname</replaceable>.core</filename></userinput>
Core was generated by `<filename><replaceable>progname</replaceable></filename>'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x7020796d.
#0 0x164a in bazz (anint=0x5) at temp.c:17
(gdb)
In this case, the program was called <filename><replaceable>progname</replaceable></filename>, so the core file is called <filename><replaceable>progname</replaceable>.core</filename>. We can see that the program crashed due to trying to access an area in memory that was not available to it in a function called <function>bazz</function>.
Sometimes it is useful to be able to see how a function was called, as the problem could have occurred a long way up the call stack in a complex program. <command>bt</command> causes <command>gdb</command> to print out a back-trace of the call stack:
(gdb) <userinput>bt</userinput>
#0 0x164a in bazz (anint=0x5) at temp.c:17
#1 0xefbfd888 in end ()
#2 0x162c in main () at temp.c:11
(gdb)
The <function>end()</function> function is called when a program crashes; in this case, the <function>bazz()</function> function was called from <function>main()</function>.
Attaching to a Running Program with gdb
One of the neatest features about <command>gdb</command> is that it can attach to a program that is already running. Of course, that requires sufficient permissions to do so. A common problem is stepping through a program that forks and wanting to trace the child, but the debugger will only trace the parent.

Loading…

User avatar None

New source string

FreeBSD Doc / books_developers-handbookEnglish

New source string a month ago
Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/para
Labels
No labels currently set.
Flags
read-only
Source string location
book.translate.xml:2148
Source string age
a month ago
Translation file
string