Effective use of GDB

February 24th 2008

01/22/08
Debugging is twice as hard as writing
the code in the first place. Therefore,
if you write the code as cleverly as
possible, you are, by definition, not
smart enough to debug it

Brian W. Kernighan's Law of

Debugging Difficulty

2
B

3
Agenda
 Programming GDB
 Defining commands
 Controlling program flow
 Inspecting and Changing Program State
 Changing Debuggee state
 Post-mortem analysis with GDB
 Core Files
 Debugging Tips, Tricks and Myths.

4
Some Definitions
 Debugger – gdb
 Debuggee – Program being debugged

5
Programming GDB.
 Code
 Commands
 Conditional Breakpoints – Default Actions with Breakpoints.
 Sequencing
 Looping
 Data
 Convenience Variables.
 Parameters to commands
 Environment
 Command files
 .gdbinit

6
Defining Custom Commands
 Build on top of basic gdb commands .
 Useful to traverse long data structures and print
values.
 Sequence of GDB commands to which you can add
a new name
 Upto 10 arguments ($arg0... $arg9) allowed .
 Supports if-else, conditional and basic looping
constructs.
 Convenience variables can be used.

7
Defining Custom Commands

(gdb) define factorial

Type commands for definition of "factorial".
End with a line saying just "end".
>set $fact=1
>set $n=$arg0
>while $n>1
>set $fact=$fact*$n
>set $n=$n-1
>end
>print $fact
>end
(gdb) factorial 5

$30 = 120.

8
Convenience Variables
 Use to hold values that can be reused.
 Variables exist within gdb and not as a part of your
debuggee.
 Prefixed with `$'
 No fixed type
 set $foo = *obj_ptr
 show convenience

9
Inspecting Debuggee State.
 Inspecting data
 Interpreter on the debuggee
 Changing debuggee program state

10
Interpreter on the debuggee
 Possible to call functions in the debuggee
 Shows return value.
 Pass multiple parameters includes convenience variables
 Usecases
 Change Debuggee state to reset or initialize
 Pretty Print large data structures
 Quickly examine behaviour of a function

 Caveats
 No breakpoints allowed in such functions
 Called routine cannot abort or the debug session will terminate
 Can't single step in such functions.

11
Changing Debuggee State
 Setting values to variables
 print var = value
 set variable name = value
 set variable name = func (....)
 Continuing from a different location
 jump linespec
 jump *address
 set $pc = value
 Return from a function
 return expr
 Giving a signal to your program
 signal {signalname | signalnumber}

12
Debugging Signals
 Sending signals to the debuggee
 Signal handlers are not special.
 Trap Execution on signal delivery
  signal <signalname /number>
 Pass a signal to a program
 Equivalent of raise.

13
Debugging Signals
handle signum/name [Keywords]
 Decide on what to do with the signal (action)
 {no}stop – Give control to the debugger.
 {no}print – Print information on the console.
 {no}pass – Pass the signal to the debuggee
 {no}ignore-
 Ignore = nopass
 noignore=pass

 Resume a program with signal 0 .

14
Core Files
 Generate core files how ?
 What is in a core file ?
 Debug a core file as you would any other program
 Backtraces Work ! up, down, Frame tracing works.
 Threads .. hmmm !

15
Generating Core Files
 $> ulimit -c unlimited
 Run your program normally
 get a core file.
 Typically a file called core or core.pid on other
distros.
 Configuring file info by
/proc/sys/kernel/core_pattern and
/proc/sys/kernel/core_uses_pid

16
What is in a core file.
 Memory and Register dump of the program being
run.
 Linker map dump from dynamic linker.
 Stack dump at time of crash.
 Default data section.
 All threads are dumped.

17
/proc/kcore
 Treat it as any other core file .
 Get a kernel compiled with debug info in it.

18
Rudimentary Replay Debugging
 Save program state
 Resume from the program state.
 Rudimentary form of replay debugging.
 Caveats
 File IO, Signals, Sockets , Threads etc.
 Shameless plug – Go look at LIZARD (Lizard iz a
Replay Debugger) http://lizard.sourceforge.net

19
Some popular Myths
 Code generated with -g is different from without it.
 Do we lose MIPS with -g ?
 Stepping forward in straight line code takes you
back in time. Hmmm compiler bug ?
 printf is my best friend !

20
Moral of the story.
 Get familiar with assembly – even if it is
rudimentary
 Trust the debugger. It usually works.
 Don't blame the compiler always . Its usually a buffer overflow
some place !
 Start automating your debug tasks.
 Define your commands.
 Write your own gdbinit scripts with your software.
 Document them !
 Structure your code better.
 Remember from the command line
 help
 info

21
Some questions
 The debugger being a user level process gets
information about other user level processes . A
security hole ?
 Software breakpoints – How big is the instruction
used?
 How do breakpoints in shared libraries work across
programs ?
 Can I use gdb on gdb ?

22
Thank you and Questions
 References
 GDB User Manual
 GDB Reference Manual

23
 www.azingo.com

01/22/08