1.1 How do I compile with debugging symbols?

[top] [toc]
Pass the -g flag to your compiler:
prompt > gcc -g program.c -o programname
NOTE: If you have a larger program with several files, each must be compiled with the -g
flag, and it must also be set when you lin!
1.2 How do I run programs with the debugger? [top] [toc]
"irst start the debugger with your program name as the first argument!
prompt> gdb programname
Ne#t use the run command in gdb to start e#ecution! Pass your arguments to this
command!
(gdb) run arg1 "arg2" ...
1.3 How do I restart a program running in the debugger? [top] [toc]
$se the kill command in gdb to stop e#ecution! The you can use the run command as
shown above to start it again!
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) run ...
1. How do I e!it the debugger? [top] [toc]
$se the "uit command!
(gdb) quit
NOTE: %ou may be ased if you want to ill the program! &nswer yes!
(gdb) quit
The program i running. !"it any#ay? (y or n) y
prompt >
1.# How do I get help on debugger commands? [top] [toc]
$se the help command! 'db has a description for every command it understand, and
there are many, many more then this tutorial covers! The argument to help is the
command you want information about! If you (ust type )help) with no arguments, you
will get a list of help topics similar to the following:
(gdb) help
$it o% clae o% command&
aliae -- 'liae o% other command
breakpoint -- (aking program top at certain point
data -- !"amining data
%ile -- )peci%ying and e"amining %ile
internal -- (aintenance command
obcure -- *bcure %eature
running -- +unning the program
tack -- !"amining the tack
tatu -- )tatu inquirie
upport -- )upport %acilitie
tracepoint -- Tracing o% program e"ecution #ithout topping
the program
uer-de%ined -- ,er-de%ined command
Type "help" %ollo#ed by a cla name %or a lit o% command
in that cla.
Type "help" %ollo#ed by command name %or %ull documentation.
-ommand name abbre.iation are allo#ed i% unambiguou.
$.2 %!ample &ebugging 'ession(
'egmentation )ault %!ample
*e are going to use gdb to figure out why the following program causes a segmentation
fault! The program is meant to read in a line of te#t from the user and print it! +owever,
we will see that in it,s current state it doesn,t wor as e#pected!!!
1 & /include 0tdio.h>
2 & /include 0tdlib.h>
1 & int main(int argc2 char 33arg.)
4 & 5
6 & char 3bu%7
8 &
9 & bu% : malloc(10011)7
; &
< & %get(bu%2 1=242 tdin)7
1=& print%(">?n"2 bu%)7
11&
12& return 17
11& @
The first step is to compile the program with debugging flags:
prompt> gcc -g eg%ault.c
Now we run the program:
prompt > a.out
Aello BorldC
)egmentation %ault
prompt >
This is not what we want! Time to fire up gdb:
prompt > gdb a.out
DE, gdb 6.=
-opyright 2=== Free )o%t#are Foundation2 Gnc.
DHI i %ree o%t#are2 co.ered by the DE, Deneral Jublic
$icene2 and you are
#elcome to change it andKor ditribute copie o% it under
certain condition.
Type "ho# copying" to ee the condition.
There i abolutely no #arranty %or DHI. Type "ho#
#arranty" %or detail.
Thi DHI #a con%igured a "i8;8-pc-linu"-gnu"...
(gdb)
*e,ll (ust run it and see what happens:
(gdb) run
)tarting program& KhomeKdga#dKcpcK181Ka.out
tet tring
Jrogram recei.ed ignal )GD)!DL2 )egmentation %ault.
="4==9%c11 in MG*MgetlineMin%o () %rom KlibKlibc.o.8
-o we received the -I'-E'. signal from the operating system! This means that we tried
to access an invalid memory address! /et,s tae a bactrace:
(gdb) backtrace
/= ="4==9%c11 in MG*MgetlineMin%o () %rom KlibKlibc.o.8
/1 ="4==9%b8c in MG*Mgetline () %rom KlibKlibc.o.8
/2 ="4==9e%61 in %get () %rom KlibKlibc.o.8
/1 =";=4;4b2 in main (argc:12 arg.:="b%%%%a%4) at
eg%ault.c&1=
/4 ="4==19%6c in MMlibcMtartMmain () %rom KlibKlibc.o.8
*e are only interested in our own code here, so we want to switch to stac frame 0 and
see where the program crashed:
(gdb) %rame 1
/1 =";=4;4b2 in main (argc:12 arg.:="b%%%%a%4) at
eg%ault.c&1=
1= %get(bu%2 1=242 tdin)
*e crashed inside the call to fgets! In general, we can assume that library functions such
as fgets wor properly 1if this isn,t the case, we are in a lot of trouble2! -o the problem
must be one of our arguments! %ou may not now that ,stdin, is a global variable that is
created by the stdio libraries! -o we can assume this one is o! That leaves us with ,buf,:
(gdb) print bu%
N1 : ="=
The value of buf is 3#3, which is the N$// pointer! This is not what we want - buf
should point to the memory we allocated on line 4! -o we,re going to have to find out
what happened there! "irst we want to ill the currently-running invocation of our
program:
(gdb) kill
Kill the program being debugged? (y or n) y
Now set a breapoint on line 4:
(gdb) break eg%ault.c&;
Ireakpoint 1 at =";=4;4;8& %ile eg%ault.c2 line ;.
Now run the program again:
(gdb) run
)tarting program& KhomeKdga#dKcpcK181Ka.out
Ireakpoint 12 main (argc:12 arg.:="b%%%%a%4) at eg%ault.c&;
; bu% : malloc(10011)7
*e,re going to chec the value of buf before the malloc call! -ince buf wasn,t initiali5ed,
the value should be garbage, and it is:
(gdb) print bu%
N2 : ="b%%%%aa; "OPQR/?199?==1StT?==1S?==1"
Now step over the malloc call and e#amine buf again:
(gdb) ne"t
1= %get(bu%2 1=242 tdin)7
(gdb) print bu%
N1 : ="=
&fter the call to malloc, buf is N$//! If you were to go chec the man page for malloc,
you would discover that malloc returns N$// when it cannot allocate the amount of
memory re6uested! -o our malloc must have failed! /et,s go bac and loo at it again:
9 & bu% : malloc(10011)7
*ell, the value of the e#pression 7 88 07 1the integer 7 left-shifted 07 times2 is
9:;9;<:;=, or 9'> 1gigabytes2! .ery few machines have this ind of memory - mine
only has :=?@>! -o of cousre malloc would fail! "urthermore, we are only reading in
73:9 bytes in the fgets call! &ll that e#tra space would be wasted, even if we could
allocate it! Ahange the 78807 to 73:9 1or 788;2, and the program will wor as e#pected:
prompt >
Aello BorldC
Aello BorldC
prompt >
-o now you now how to debug segmentation faults with gdb! This is e#tremely useful 1I
use it more often then I care to admit2! The e#ample also illustrated another very
important point: &/*&%- A+EAB T+E CET$CN .&/$E O" @&//OAD +ave a nice
day!
1. *hat is +debugging+
Eebugging is the process of removing bugs from computer programs! On one end of the
spectrum, debugging means staring at your source code until you see the bug! &n
infinitely more effective method is to use a special program called a )debugger)!
2. *hat is a +debugger+
& debugger is a program that runs other programs! & debugger lets the user 1programmer2
stop running the program at any time and poe around internally! %ou can e#amine and
change memory contents, call functions, and loo at system registers! >esides all these
fun things, a debugger can be used to fi# your programs!
3. *hy use a debugger? Isn,t print-.cout.'ystem.out.println good enough?
$sing a debugger is 1generally2 the most efficient way to find bugs in your program!
+aving your program print debugging output is a valid method of finding bugs, and in
some cases is the onlyFeasiest way to go! Eebuggers show their strength when it comes to
common bugs lie infinite loops or segmentation faults! %ou can spin your wheels for
hours printing output, where a debugger would point out the problem instantly!
. *hat about !db? /isual &ebugger? *here is my 01I?2?
.isual debuggers are great! They mae debugging much easier! >ut you won,t always
have a visual environment to wor in! If you learn to use a command-line debugger lie
gdb, you can use any debugger in e#istence, visual or not! "urthermore, for some
applications special debuggers have been built, and these debuggers are generally
command-line only 1eg: db, the ernel debugger2!
#. )inding the line number in my program takes too long2
$sing pageupFpagedown and the arrow eys is about the least effective way to find a line
a number! If you use the emacs te#t editor 1which the author highly recommends2, place
the following commands in your !emacs file in your home directory!
(global-unet-key U??(-lV)
(global-et-key U??(-lV Wgoto-line)
Now when you press the ey se6uence 1E-A,l2, emacs will prompt you for a line number
to (ump to! +andy, noG
3. *here can I get more in-ormation about command x?
The 'N$ infopages for gdb fully document every command! Cun in-o gdb from the
shell!
Using gdb
Adobe PDF Format
The GNU debugger, gdb, is your best friend when one of your programs continually
crashes and you don't now why! gdb allows you to run your program inside of a
controlled en"ironment # you can arbitrarily start and stop e$ecution, watch the
"alues of "ariables change, trace e$ecution one line at a time, and e"en analy%e the
results of a program crash to see what went wrong! gdb includes all the features
found in other debugging products, such as those included with &orland's '((
&uilder and )icrosoft *isual +tudio ,there's more than a passing resemblance
between the *isual +tudio debugger and gdb # )icrosoft has been nown to -borrow-
code now and then.! gdb is a te$t#based debugger, but there are graphical interfaces
to it for those that insist on point#and#clic!
This document wals through a typical gdb debugging session! The code being
debugged is "ery simplistic, but the same commands and principles apply to much
more complicated programs!
The complete source code for the program being debugged is included at the end of
this document, if you want to place it on your system and follow along with the
demonstration! ,)ae sure you ha"e gdb installed on your system first.!
Assuming that we'"e /ust finished writing our program named example.c, we want to
compile and run it to mae sure it wors!
hemicuda demo> gcc -o example example.c
hemicuda demo> ./example
Gnitial matri" content&
1 2 1 4 6 8 9 ; < 1=
2 4 8 ; 1= 12 14 18 1; 2=
1 8 < 12 16 1; 21 24 29 1=
4 ; 12 18 2= 24 2; 12 18 4=
6 1= 16 2= 26 1= 16 4= 46 6=
8 12 1; 24 1= 18 42 4; 64 8=
9 14 21 2; 16 42 4< 68 81 9=
; 18 24 12 4= 4; 68 84 92 ;=
< 1; 29 18 46 64 81 92 ;1 <=
1= 2= 1= 4= 6= 8= 9= ;= <= 1==
)egmentation Fault(coredump)
0hoops1 +omething in the program is definitely broen, and the coredump message
indicates that the operating system s2uashed it lie a bug! +ince it's 3455am and we
ha"en't slept in 67 hours, a 2uic glance o"er the source code doesn't shed any light
on what's causing the problem!
&efore we can cran up gdb, we ha"e to recompile the program with debugging
symbols enabled and optimi%ations disabled! The -g option tells most compilers to
include symbolic information about the program in the e$ecutable file # this maes it
easier for the programmer to figure out what's going on since value maes more
sense than 0x149387602! The option -O0 ,that's the capital letter oh followed by the
number %ero. tells most compilers not to perform any sort of optimi%ation! This is
important, because most compiler optimi%ations are e$tremely comple$! Unless you
helped write the compiler, trying to debug an optimi%ed program is impossible!
8$ecution appears to hop from line to line in no logical order, the "alues of "ariables
don't mae sense at "arious locations, and so on!
hemicuda demo> gcc -g -O0 -o example example.c
Now that we ha"e a "ersion of our program suitable for debugging, we can open it
inside of gdb!
hemicuda demo> gdb example
DE, gdb 6.=
-opyright 2=== Free )o%t#are Foundation2 Gnc.
DHI i %ree o%t#are2 co.ered by the DE, Deneral Jublic $icene2 and
you are
#elcome to change it andKor ditribute copie o% it under certain
condition.
Type "ho# copying" to ee the condition.
There i abolutely no #arranty %or DHI. Type "ho# #arranty" %or
detail.
Thi DHI #a con%igured a "parc-un-olari2.<"...
(gdb)
The (gdb) prompt tells us that gdb is ready and awaiting commands! Typing help at
the prompt will gi"e you a list of a"ailable commands!
The first thing we want to do is run the program inside of the debugger to see
e$actly where it dies!
(gdb) run
)tarting program& KlamontKde.elopmentKdemoKe"ample
Gnitial matri" content&
1 2 1 4 6 8 9 ; < 1=
2 4 8 ; 1= 12 14 18 1; 2=
1 8 < 12 16 1; 21 24 29 1=
4 ; 12 18 2= 24 2; 12 18 4=
6 1= 16 2= 26 1= 16 4= 46 6=
8 12 1; 24 1= 18 42 4; 64 8=
9 14 21 2; 16 42 4< 68 81 9=
; 18 24 12 4= 4; 68 84 92 ;=
< 1; 29 18 46 64 81 92 ;1 <=
1= 2= 1= 4= 6= 8= 9= ;= <= 1==
Jrogram recei.ed ignal )GD)!DL2 )egmentation %ault.
="1=b4c in tran%orm(atri" (matri":="e%%%%b4=) at e"ample.c&6;
6; matri"UiVUXV : bimod(matri"UiVUXV)7
According to gdb, the error is occurring on line 37! This line is inside the
transformMatrix() function and is a call to the bimod() function! The bimod()
function is so simple that we're pretty sure it's not the problem, so something in
transformMatrix() must be causing our error!
9ur ne$t step is to use the list command to print the code surrounding line 37 so
we can get an idea of where we are in the program!
(gdb) list
61 5
64 int i2 X7
66
68 %or (i : =7 i 0 1==7 iYY)
69 %or (X : =7 X 0 1==7 XYY)
6; matri"UiVUXV : bimod(matri"UiVUXV)7
6< @
8=
81
82
+etting a breapoint in the transformMatrix() function will halt the program's
e$ecution and let us step through the code one line at a time! A breapoint can be
set either by specifying the name of the function or a line number # the e$ample
below uses the name of the function, but the command break 56 would do the same
thing!
(gdb) break transformMatrix
Ireakpoint 1 at ="1=aec& %ile e"ample.c2 line 68.
Now if we run the program again, it will stop at the beginning of transformMatrix()
and wait for further instructions!
(gdb) run
The program being debugged ha been tarted already.
)tart it %rom the beginning? (y or n) y
)tarting program& KlamontKde.elopmentKdemoKe"ample
Gnitial matri" content&
1 2 1 4 6 8 9 ; < 1=
2 4 8 ; 1= 12 14 18 1; 2=
1 8 < 12 16 1; 21 24 29 1=
4 ; 12 18 2= 24 2; 12 18 4=
6 1= 16 2= 26 1= 16 4= 46 6=
8 12 1; 24 1= 18 42 4; 64 8=
9 14 21 2; 16 42 4< 68 81 9=
; 18 24 12 4= 4; 68 84 92 ;=
< 1; 29 18 46 64 81 92 ;1 <=
1= 2= 1= 4= 6= 8= 9= ;= <= 1==
Ireakpoint 12 tran%orm(atri" (matri":="e%%%%b2;) at e"ample.c&68
68 %or (i : =7 i 0 1==7 iYY)
Now we can run through code one line at a time using the next command!
(gdb) next
69 %or (X : =7 X 0 1==7 XYY)
(gdb) next
6; matri"UiVUXV : bimod(matri"UiVUXV)7
8"en though we're fairly confident that the bimod() function isn't the problem, we
can use the step command to trace through it instead of simply e$ecuting it lie
next would /ust to be sure!
(gdb) step
bimod (.alue:1) at e"ample.c&86
86 i% (.alue > 2 :: =)
(gdb) next
8; return(=)7
(gdb) next
8< @
(gdb) next
tran%orm(atri" (matri":="e%%%%b2;) at e"ample.c&69
69 %or (X : =7 X 0 1==7 XYY)
0hen we step into the function, gdb prints the function name, the "alues that are
passed to it as "ariables, and the line number that it starts on! The next command
lets us wal through bimod(), and puts us bac in transformMatrix() when
bimod() finishes!
Now that we'"e waled through the functions once, let's clear the breapoint and
continue e$ecuting the program! 0e now the program is still going to stop
e$ecuting when the problem occurs!
(gdb) clear transformMatrix
Heleted breakpoint 1
(gdb) continue
-ontinuing.
Jrogram recei.ed ignal )GD)!DL2 )egmentation %ault.
="1=b4c in tran%orm(atri" (matri":="e%%%%b2;) at e"ample.c&6;
6; matri"UiVUXV : bimod(matri"UiVUXV)7
+ometimes using the print command to e$amine the "alues of "ariables can pro"ide
a clue to what went wrong! :et's loo at the three "ariables used in the
transformMatrix() function # i, j , and matrix!
(gdb) print matrix
N1 : (int (3)U1=V) ="e%%%%b2;
(gdb) print i
N2 : 22
(gdb) print j
N1 : <=
As the 'rocodile ;unter would say, -'riey1-
The "alue of matrix is what we would e$pect, but the "alues for i and j are way out
of the range they should be in! They're used to reference elements in a <=5><=5>
matri$ # no wonder there was a problem when they tried to reference the element at
<??><@5>1
A 2uic loo at the loops that set the "alues of i and j tell the story # a programmer
wasn't paying attention and added an e$tra %ero to the upper bound of the loop!
After e$iting gdb, the loop conditions can be changed to fi$ the problem!
(gdb) quit
The program i running. !"it any#ay? (y or n) y
hemicuda demo>
Source Code

#include <stdlib.h>
#include <stdio.h>
//function prototypes
void transformMatrix(int matrix[10][10]);
int bimod(int value);
int main()
{
int i, j;
int matrix[10][10];
//load values into matrix
for (i = 0; i < 10; i++)
{
for (j = 0; j < 10; j++)
{
matrix[i][j] = (i+1) * (j+1);
}
}
//display initial contents of matrix
printf("Initial matrix contents:\n");
for (i = 0; i < 10; i++)
{
for (j = 0; j < 10; j++)
{
printf("%4i", matrix[i][j]);
}
printf("\n");
}
transformMatrix(matrix);
//display transformed contents of matrix
printf("\nTransformed matrix contents:\n");
for (i = 0; i < 10; i++)
{
for (j = 0; j < 10; j++)
{
printf("%4i", matrix[i][j]);
}
printf("\n");
}
exit(0);
}
void transformMatrix(int matrix[10][10])
{
int i, j;
for (i = 0; i < 100; i++)
for (j = 0; j < 100; j++)
matrix[i][j] = bimod(matrix[i][j]);
}
int bimod(int value)
{
if (value % 2 == 0)
return(1);
else
return(0);
}


What is a segmentation fault?
0hen your program runs, it has access to certain portions of memory! First, you ha"e local "ariables
in each of your functionsA these are stored in the stac! +econd, you may ha"e some memory,
allocated during runtime ,using either malloc, in ', or new, in '((., stored on the heap ,you may
also hear it called the -free store-.! Bour program is only allowed to touch memory that belongs to it
## the memory pre"iously mentioned! Any access outside that area will cause a segmentation fault!
+egmentation faults are commonly refered to as segfaults!
There are four common mistaes that lead to segmentation faults4 dereferencing NU::,
dereferencing an uninitiali%ed pointer, dereferencing a pointer that has been freed ,or deleted, in '(
(. or that has gone out of scope ,in the case of arrays declared in functions., and writing off the
end of an array!
A fifth way of causing a segfault is a recursi"e function that uses all of the stac space! 9n some
systems, this will cause a -stac o"erflow- report, and on others, it will merely appear as another
type of segmentation fault!
The strategy for debugging all of these problems is the same4 load the core file into GD&, do a
bactrace, mo"e into the scope of your code, and list the lines of code that caused the segmentation
fault!
&ebugging code
&s an e#ample, consider the following 1slightly faulty2 program 1myprog!c2:
/include 0tdio.h>

int main (int argc2 char 33arg.)
5
int i7

print% ("Aello2 #orldC?n")7

K3 print %irt character o% command-line argument 3K
%or (i:=7 i0:argc7 iYY) 5
print% (">c"2 arg.UiVU=V)7
@
print% ("?n")7

return =7
@
This is compiled using the following:
bahN gcc -Ball -ggdb -o .Kmyprog .Kmyprog.c
*hen run, this program prints the hello message then segfaults:
bahN .Kmyprog
Aello2 #orldC
)egmentation %ault
Thus to find what the problem is, the debugger is used! "or my /inu# 1debianFunstable2
bo#, gdb prints:
bahN gdb .Kmyprog
DE, gdb 6.1-debian
-opyright 2==2 Free )o%t#are Foundation2 Gnc.
DHI i %ree o%t#are2 co.ered by the DE, Deneral Jublic $icene2 and
you are
#elcome to change it andKor ditribute copie o% it under certain
condition.
Type "ho# copying" to ee the condition.
There i abolutely no #arranty %or DHI. Type "ho# #arranty" %or
detail.
Thi DHI #a con%igured a "i1;8-linu""...
(gdb)
Once that,s loaded, the program can be run from within the debugger using the H(r) run,
command! &ny arguments that would normally be passed to the program are given here!
'E> will run the program until it terminates, receives a stopping signal 1HHsegmentation
fault,, 1)GD)!DL2 is one of these2, or until a breapoint is reached! "or e#ample:
(gdb) r ome argument 42
)tarting program& KtorageKhomeK%rmb2KtoyKcKmyprog ome argument
42
Aello2 #orldC
Jrogram recei.ed ignal )GD)!DL2 )egmentation %ault.
="=;=4;18c in main (argc:42 arg.:="b%%%%cb4) at myprog.c&12
12 print% (">c"2 arg.UiVU=V)7
(gdb)
This shows where the program crashed -- in this case on line 7: of Hmyprog.c,, and gdb
helpfully shows the offending line of code!
-ometimes a program will crash in code outside that being debugged! "or e#ample, if the
H%ree(), library-call is called with a N$// pointer! To figure out where it was called
from, the H(bt) backtrace, command is used! "or Hmyprog,, this is not terribly e#citing,
since only Hmain(), is involved! >ut:
(gdb) bt
/= ="=;=4;18c in main (argc:42 arg.:="b%%%%cb4) at myprog.c&12
(gdb)
This shows the functions called 1Hstac frames,2, with 3 being the frame where the
program crashed, moving upwards to the last, that will be Hmain(),! In the above
e#ample, there is only one stac frame to show! >y default, frame 3 is active when the
debugger resumes after a crash! If the code of interest is not frame 3, then the correct
frame must be selected! This is done using the H(%) %rame, command, for e#ample:
(gdb) % =
/= ="=;=4;18c in main (argc:42 arg.:="b%%%%cb4) at myprog.c&12
12 print% (">c"2 arg.UiVU=V)7
Once some offending code has been located, variables can be inspected in an attempt to
determine what went wrong! "or this code, the only reasonable e#planation is that an
attempt to access HHarg.UiVU=V,, is causing the segmentation fault! The H(p) print,
command is used to inspect the values of e#pressions, and should be approached
incrementally, for e#ample:
(gdb) p arg.
N1 : (char 33) ="b%%%%cb4
(gdb) p i
N2 : 4
(gdb) p arg.UiV
N1 : ="=
(gdb)
and thus the error is found -- HHarg.UiV,, is N$// 15ero2, so attempting to access its
elements will cause a segmentation fault 1by N$// dereference in this case2! The cause
of the error is something else, and may re6uire close inspection of the code to figure out
what the real problem is! & functional, but not entirely clean solution, would be to modify
the loop to chec for N$// cases:
%or (i:=7 i0:argc7 iYY) 5
i% (arg.UiV C: E,$$) 5
print% (">c"2 arg.UiVU=V)7
@
@
+owever, this is not the real problem! The loop itself is wrong, since on the last iteration
Hi, is Hargc,I and Harg.UargcV, is not a valid command-line argument! The last valid
argument is Harg.Uargc-1V,! "i#ing the loop is trivial:
%or (i:=7 i0argc7 iYY) 5
print% (">c"2 arg.UiVU=V)7
@
&fter editing and re-compiling, the program wors as e#pected:
bahN .Kmyprog %oo bar co
Aello2 #orldC
.%bc
'etting breakpoints and stepping
-ometimes it is desirable to stop a program at a specific point, before it crashes! This is
particularly useful for investigating suspect code, since breapoints can be moved around
to help trac down the bug! The H(b) break, command is used to set a breapoint! "or
the fairly boring e#ample above, we might want to stop e#ecution when the H%or(), loop
on line 77 is reached! Thus:
(gdb) b myprog.c&11
Ireakpoint 1 at =";=4;14;& %ile myprog.c2 line 11.
(gdb)
&dditional breapoints can be set without restriction! To delete a breapoint, the H(d)
delete, command is used, giving a breapoint number as an optional argument! *ithout
arguments, this command will delete all breapoints 1but will as first2! To show the
current breapoints, the command H(i b) in%o breakpoint, is used! "or e#ample:
(gdb) i b
Eum Type Hip !nb 'ddre Bhat
1 breakpoint keep y ="=;=4;14; in main at myprog.c&11
The program is run as normal from within the debugger, but will stop if it reaches a
breapoint 1before terminating or receiving a signal2! 'E> reports the breapoint
number, filename and line-number where the brea occured! "or e#ample:
(gdb) r %oo bar co
)tarting program& KtorageKhomeK%rmb2KtoyKcKmyprog %oo bar co
Aello2 #orldC
Ireakpoint 12 main (argc:42 arg.:="b%%%%cc4) at myprog.c&11
11 %or (i:=7 i0argc7 iYY) 5
(gdb)
.ariables and the bactrace can be inspected in the normal way! To continue after a
breapoint, or a crash, the commands H() tep, and H(c) continue, are generally
useful 1there are additional ones too2! The Hstep, command attempts to step to the ne#t
line of source code, going into function calls for which it has debugging information! The
Hcontinue, command resumes e#ecution proper, until the program reaches another 1or
possibly the same2 breapoint, terminates or receives a signal