SD-CC

GDB tutorial
There is probably no person capable of writing complicated pieces of code
which will work from the first run. Once you get over the compilation
errors, you might still expect some runtime errors, which are worse. If the
compiler is good enough to give us hints about our errors (either we have
typos, or we use undefined structures, or the function call and function
header do not match), at runtime errors are more subtle and usually harder
to catch.
What kind of errors can we expect during runtime? Referencing a NULL
pointer, working with unopened files, division by 0 or simple error which are
correct for the compiler (for example an if (x = 2) is correct for the compiler,
but for sure we didnt want that to happen).
For simple programs we can use printf(message\n) to help us debug.
This will give us some hints about where our code crashes. Please be careful
when using this method of debugging. Every message must end with \n, or
else what we see might not be correct. The printf function only prints in one
of the following situation: the internal buffer it uses is full, and it will be
ejected to the output; or an explicit call is made to free the buffer (by using
\n for example).
Of course, this method is not the best. It is good for small codes, for codes
written by you and it is good if you also have hints about what might be
wrong.
What is there to do in all the other cases?

GDB The GNU Project Debugger

This allows you to see what is going on inside another program while it
executes or what another program was doing at the moment it crashed.
The most important thing to do when you want to inspect your program
using GDB is to enable the debugging glad at compilation: that is -g.

Starting and stoping the debugger

gdb a.out -> run / run arg1 arg2 / run < file
gdb args ./a.out arg1 arg2 -> run
quit

Useful commands

break 45 (breakpoint at line 45 in the current file)

break file.c:45 (breakpoint at line 45 in file file.c)
break function (breakpoint at the beginning of function)
watch x == 3 (the program will pause when variable x gets value 3)
continue (the program continues and will stop at the next breakpoint)
info break (lists all the breakpoints)
d 1 (deletes breakpoint number 1)
print x (print the value of variable x)
display x (constantly display value of x after each step)
undisplay x (the reverse of the above command)
bt (print the function stack) useful after an error to see where the
program finished
s (runs the next line of the code)
s N (runs the next N lines of the code)
n (like s, but it does not step into functions)

Exercises
Please download the archive attached to this laboratorys folder.
1. Exercise 1
Compile the ex1.c file using -g flag. Do not look at the source code yet.
Try to run the executable like this ./a.out. Does it break? GOOD.
Now open the executable with GDB and try to find the source of your
failure. After you talk with your assistant, try to repair this failure. Please
make sure no one ever can make this mistake again.
2. Exercise 2
Now your ex1.c file compiles and also runs OK. But are you sure it is ok?
Are you always unlucky? Or did you find any strange behavior? Use gdb to
investigate which might be the problem.
3. Exercise 3
Am ramas in pana de idei ))