Labels

Sunday 17 December 2017

GDB tutorial. What is gdb and how to run commands in gdb?

GDB Tutorial

GDB, short for GNU Debugger, is the most popular debugger for UNIX systems to debug C and C++ programs.

A debugger is a program that runs other programs, allowing the user to exercise control over these programs, and to examine variables when problems arise.
GNU Debugger, which is also called gdb, is the most popular debugger for UNIX systems to debug C and C++ programs.
GNU Debugger helps you in getting information about the following:
  • If a core dump happened, then what statement or expression did the program crash on?
  • If an error occurs while executing a function, what line of the program contains the call to that function, and what are the parameters?
  • What are the values of program variables at a particular point during execution of the program?
  • What is the result of a particular expression in a program?

How GDB Debugs?

GDB allows you to run the program up to a certain point, then stop and print out the values of certain variables at that point, or step through the program one line at a time and print out the values of each variable after executing each line.
GDB uses a simple command line interface.

Points to Note

Even though GDB can help you in finding out memory leakage related bugs, but it is not a tool to detect memory leakages.

GDB cannot be used for programs that compile with errors and it does not help in fixing those errors.

GDB Commands:

GDB offers a big list of commands, however the following commands are the ones used most frequently:
  • b main - Puts a breakpoint at the beginning of the program
  • b - Puts a breakpoint at the current line
  • b N - Puts a breakpoint at line N
  • b +N - Puts a breakpoint N lines down from the current line
  • b fn - Puts a breakpoint at the beginning of function "fn"
  • d N - Deletes breakpoint number N
  • info break - list breakpoints
  • r - Runs the program until a breakpoint or error
  • c - Continues running the program until the next breakpoint or error
  • f - Runs until the current function is finished
  • s - Runs the next line of the program
  • s N - Runs the next N lines of the program
  • n - Like s, but it does not step into functions
  • u N - Runs until you get N lines in front of the current line
  • p var - Prints the current value of the variable "var"
  • bt - Prints a stack trace
  • u - Goes up a level in the stack
  • d - Goes down a level in the stack
  • q - Quits gdb

Getting Started: Starting and Stopping

  • gcc -g myprogram.c
    • Compiles myprogram.c with the debugging option (-g). You still get an a.out, but it contains debugging information that lets you use variables and function names inside GDB, rather than raw memory locations (not fun).
  • gdb a.out
    • Opens GDB with file a.out, but does not run the program. You’ll see a prompt (gdb) - all examples are from this prompt.
  • r
  • r arg1 arg2
  • r < file1
    • Three ways to run “a.out”, loaded previously. You can run it directly (r), pass arguments (r arg1 arg2), or feed in a file. You will usually set breakpoints before running.
  • help
  • h breakpoints
    • Lists help topics (help) or gets help on a specific topic (h breakpoints). GDB is well-documented.
  • q - Quit GDB

Stepping through Code

Stepping lets you trace the path of your program, and zero in on the code that is crashing or returning invalid input.
  • l
  • l 50
  • l myfunction
    • Lists 10 lines of source code for current line (l), a specific line (l 50), or for a function (l myfunction).
  • next
    • Runs the program until next line, then pauses. If the current line is a function, it executes the entire function, then pauses. next is good for walking through your code quickly.
  • step
    • Runs the next instruction, not line. If the current instruction is setting a variable, it is the same as next. If it’s a function, it will jump into the function, execute the first statement, then pause. step is good for diving into the details of your code.
  • finish
    • Finishes executing the current function, then pause (also called step out). Useful if you accidentally stepped into a function.

Breakpoints or Watchpoints

Breakpoints play an important role in debugging. They pause (break) a program when it reaches a certain point. You can examine and change variables and resume execution. This is helpful when some input failure occurs, or inputs are to be tested.
  • break 45
  • break myfunction
    • Sets a breakpoint at line 45, or at myfunction. The program will pause when it reaches the breakpoint.
  • watch x == 3
    • Sets a watchpoint, which pauses the program when a condition changes (when x == 3 changes). Watchpoints are great for certain inputs (myPtr != NULL) without having to break on every function call.
  • continue
    • Resumes execution after being paused by a breakpoint/watchpoint. The program will continue until it hits the next breakpoint/watchpoint.
  • delete N
    • Deletes breakpoint N (breakpoints are numbered when created).

Setting Variables

Viewing and changing variables at runtime is a critical part of debugging. Try providing invalid inputs to functions or running other test cases to find the root cause of problems. Typically, you will view/set variables when the program is paused.
  • print x
    • Prints current value of variable x. Being able to use the original variable names is why the (-g) flag is needed; programs compiled regularly have this information removed.
  • set x = 3
  • set x = y
    • Sets x to a set value (3) or to another variable (y)
  • call myfunction()
  • call myotherfunction(x)
  • call strlen(mystring)
    • Calls user-defined or system functions. This is extremely useful, but beware of calling buggy functions.
  • display x
    • Constantly displays the value of variable x, which is shown after every step or pause. Useful if you are constantly checking for a certain value.
  • undisplay x
    • Removes the constant display of a variable displayed by display command.

Backtrace and Changing Frames

A stack is a list of the current function calls - it shows you where you are in the program. A frame stores the details of a single function call, such as the arguments.
  • bt
    • Backtraces or prints the current function stack to show where you are in the current program. If main calls function a(), which calls b(), which calls c(), the backtrace is
  • c <= current location 
    b 
    a 
    main 
    
  • up
  • down
    • Move to the next frame up or down in the function stack. If you are in c, you can move to b or a to examine local variables.
  • return
    • Returns from current function.

Handling Signals

Signals are messages thrown after certain events, such as a timer or error. GDB may pause when it encounters a signal; you may wish to ignore them instead.
  • handle [signalname] [action]
  • handle SIGUSR1 nostop
  • handle SIGUSR1 noprint
  • handle SIGUSR1 ignore
    • Instruct GDB to ignore a certain signal (SIGUSR1) when it occurs. There are varying levels of ignoring.

To debug a program 'my_program' that has crashed and produced a core file named 'core', type the following at the command line:
gdb my_program core 
As this is mostly equivalent to starting gdb and typing the 'r' command, all of the commands above could now be used to debug the file.

The text user interface

GDB TUI
GDB features a text user interface for code, disassembler and registers. For instance:
  • Ctrl-x 1 will show the code pane
  • Ctrl-x a will hide the TUI panes
None of the GUI interfaces to gdb (Qt Creator stands out for being intuitive and easy to use) can offer access to all of the gdb functionality.

References:

https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques