Saturday, May 12, 2012

GDB V/S BUGS - I

Gdb vs Bugs..yup,this is the most apt title I could earmark for this post.In this post,I'll unwrap the power of gdb in debugging our C-programs.

To start with,let me give you an idea about how gdb can help you with your programs.So, with gdb,you can inspect what your program is doing at a certain point during execution,with different test variables.You can check or change a variable's value,skip or add a part of the code,dyanamically resolve a bug in the code,all these in b/w the execution.In progs including recursion,at any stage you can analyse all the previous calls,stored on the stack.On the whole,you CAN know whats happening inside your program.

So,lets kickoff with some brief introduction:
GDB(The GNU debugger),originated by Richard stallmen,is a free software under the GPL license,and can be used for other languages also, like c++,fortran.
In C, to make our executable file work with gdb,we have to use an extra '-g' flag,when we compile the code.This enables the gdb to implant some "debugging symbols" in the file, that help it with running the code.After that,to start gdb,jst run the command:'gdb "executable name"'.
e.g gdb a.out
gdb has an interactive shell, much like the terminal one. It can recall history with the arrow keys, executes the previous command with a 'return' hit, auto-complete words (most of the time) with the TAB key, and has other nice features.

Enough with the introduction part,lets jump to our program now:
To execute our program in gdb,we have the "run" command.It simply runs our program till the end or the first 'breakpoint'(explained later),if set, provided there is no error in the program and if it has errors,we should get some output like the line or function with its parameters, where the program crashed.
Imp to note that for seg fault,program receives "SIGSEGV" signal from the kernel.

Now, for debugging, we come to the most important term of gdb,'Breakpoints',rather "The Breakpoints"(recalling their importance).Breakpoints, as the name suggests,are the points in our program,set by us, that enable us to stop the program in between and look around it.This is necessary for systematic investication of aur program, to debug it.
We can set these breakpoints by the 'break' command."break space line_num" sets a breakpoint at that line number.We can also break the program at a specefic function,
e.g 'break main' will stop the program whenever the main function starts.
We can set as many breakpoints as we want and after setting a breakpoint(bp),we will get some info about that bp,including its number.You will need this number for referring to this bp later.Now,once you have set the bp's, run again.Execution will stop at the point specified by you.

After hitting the bp,you can inspect your program status at that point.To further execute the program,we have different functions.One is 'continue',which will run the program till next bp(if none is there,till the end).Second is "Step", which gives you a fine-grained control, by running the program line-by-line.So,you can now check your program's status even after each line.Similar to step,the third funtion is 'next',except this one doesn't execute each line of a sub-routine, rather treats it as a single instruction.But typing step or next each time can be tidious..ryt.
No worries,gdb has a solution for this also.If you hit RETURN,it will run the same command you just entered.

Stopped the program,time to check it out!
But how?
You can use "print" command to print any variables's value(print variable_name).Talking of checking the prog,there is one more important term-"watchpoints".Whereas breakpoints interrupt the program at a particular line or function, watchpoints act on variables.They pause the program whenever a watched variable’s value is modified.
e.g. 'watch i' will interrupt the program whenever i changes and print the new and old values.
But it relies on the variable's scope,relative to where we are at the time of watch.
There are other commands like info breakpoints,delete, whose name indicate their functions.

There are other things also in gdb like conditional breakpoints,commands combined with breakpoints,fixing program errors dynamically,jumping over misbehaving code,backtrace(mainly in recursive programs),core dumps,relating the breakpoints and many other.These all will be included in my upcoming posts.

Any queries regarding the above post are welcomed.
So, adios till then! and this time, I am sure this post will be helpful.




 

No comments: