GDB - The GNU Debugger

;; evaluate each line inside an emacs buffer with C-x C-e

(info "(gdb)")

(info "(gdb) Auto-loading safe path")

(info "(emacs) Debuggers")

(info "(emacs) Starting Gud")

gdb with new Text User Interface

#bash>$
gdb -tui  program

or Ctrx-x-a to activate from inside GDB

To disable auto-loading safe path:

~/.gdbinit

set auto-load safe-path /

It might be that we'll want to debug a program that cannot be launched from the command line. This may be because the program is launched from some system daemon (such as a CGI program on the web), and we are too lazy to make it possible to run it directly from the command line. Or perhaps the program takes very long time to run its initialization code, and starting it with a debugger attached to it will cause this startup time to be much much longer. There are also other reasons, but hopefully you got the point. In order to do that, we will launch the debugger in this way:

$ sudo gdb debug_me 9561

Here we assume that "debug_me" is the name of the program executed, and that 9561 is the process id (PID) of the process we want to debug. What happens is that gdb first tries looking for a "core" file named "9561" (we'll see what core files are in the next section), and when it won't find it, it'll assume the supplied number is a process ID, and try to attach to it. If there process executes exactly the same program whose path we gave to gdb (not a copy of the file. it must be the exact same file that the process runs), it'll attach to the program, pause its execution, and will let us continue debugging it as if we started the program from inside the debugger. Doing a "where" right when we get gdb's prompt will show us the stack trace of the process, and we can continue from there. Once we exit the debugger, It will detach itself from the process, and the process will continue execution from where we left it.

Also can be done from emacs:

sudo emacs

M-x gdb

Run gdb (like this): gdb -i=mi   program_name   pid

where pid is the pid number

then use where, list, put break points … then continue

print and many other GDB commands accept an expression and compute its value. Any kind of constant, variable or operator defined by the programming language you are using is valid in an expression in GDB. This includes conditional expressions, function calls, casts and string constants. It unfortunately does not include symbols defined by preprocessor #define commands.

how do I print a #defined constant in GDB? http://stackoverflow.com/questions/2934006/how-do-i-print-a-defined-constant-in-gdb I have some constants hash defined like so:

#define CONST 40

help macro

You must compile with the -g3 flag for it to work and start your program before the macros are loaded.

-g3 flags to ensure the compiler includes information about preprocessor macros in the debugging information.

In your case:

info macro CONST

or

macro expand CONST

More info: http://sourceware.org/gdb/current/onlinedocs/gdb/Macros.html

ptype <VAR> will print the structure of a pointer

ptype struct <STRUCTNAME> will print struct

(gdb) ptype fstatus
type = struct fstatus {
    int failed;
    struct stat st;
} *

(gdb) ptype struct stat
type = struct stat {
    __dev_t st_dev;
    __ino_t st_ino;
    __nlink_t st_nlink;
    __mode_t st_mode;
    __uid_t st_uid;
    __gid_t st_gid;
    int __pad0;
    __dev_t st_rdev;
    __off_t st_size;
    __blksize_t st_blksize;
    __blkcnt_t st_blocks;
    struct timespec st_atim;
    struct timespec st_mtim;
    struct timespec st_ctim;
    __syscall_slong_t __glibc_reserved[3];
}

(gdb) p (struct fstatus) *fstatus
$22 = {failed = 0, st = {st_dev = 0, st_ino = 0, st_nlink = 0, st_mode = 0, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 0, st_blksize = 0, st_blocks = 0, st_atim = {tv_sec = 0, tv_nsec = 0}, st_mtim = {tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec = 0}, __glibc_reserved = {0, 0, 0}}}

C-x <SPC> set breakpoint at current line number

GUD prefix: C-c any buffer prefix: C-x C-a

ON GUD: ON ANY buffer DESCRIPTION

C-c C-b C-x C-a C-b set breakpoint at current line C-d delete breakpoint C-f step out of function

gdb-many-windows

27.6.5.1 GDB User Interface Layout …………………………….

If the variable `gdb-many-windows' is `nil' (the default), `M-x gdb' normally displays only the GUD interaction buffer. However, if the variable `gdb-show-main' is also non-`nil', it starts with two windows: one displaying the GUD interaction buffer, and the other showing the source for the `main' function of the program you are debugging.

If `gdb-many-windows' is non-`nil', then `M-x gdb' displays the following frame layout:

If you ever change the window layout, you can restore the "many windows" layout by typing `M-x gdb-restore-windows'. To toggle between the many windows layout and a simple layout with just the GUD interaction buffer and a source file, type `M-x gdb-many-windows'.

You may also specify additional GDB-related buffers to display, either in the same frame or a different one. Select the buffers you want by typing `M-x gdb-display-BUFFERTYPE-buffer' or `M-x gdb-frame-BUFFERTYPE-buffer', where BUFFERTYPE is the relevant buffer type, such as `breakpoints'. You can do the same with the menu bar, with the `GDB-Windows' and `GDB-Frames' sub-menus of the `GUD' menu.

When you finish debugging, kill the GUD interaction buffer with `C-x k', which will also kill all the buffers associated with the session. However you need not do this if, after editing and re-compiling your source code within Emacs, you wish to continue debugging. When you restart execution, GDB automatically finds the new executable. Keeping the GUD interaction buffer has the advantage of keeping the shell history as well as GDB's breakpoints. You do need to check that the breakpoints in recently edited source files are still in the right places.

1.5.3 Watchpoints Combines the notions of breakpoint and variable inspection. The most basic form instructs the debugger to pause execution of the program whenever the value of a specified variable changes. For example, suppose that you wish to examine a progra's state during the points in the course of its execution at which the variable z changes value. In GDB, you can issue the command:

(gdb) watch z

When you run the program, GDB will pause execution whenever the value of z changes.

Even better, you can set watchpoints based on conditional expressions. Say for example, that you wish to find the first point in the execution of the program at which the value of z exceeds 28. In GDB, you would type

(gdb) watch (z > 28)

When z first takes on a value larger than 28, the value of the expression (z >28) will change from 0 to 1, and GDB will pause execution of the program.

Watchpoints are usually not as useful for local variables as they are for variables with wider scope, because a watchpoint set on a local variable is canceled as soon as the variable goes out of scope. However, local variables in main() are an obvious exception, as such variables are not deallocated until the program finishes execution.

You can optionally have 'gdb' pass any arguments after the executable file to the inferior using '–args'. This option stops option processing. gdb –args gcc -O2 -c foo.c This will cause 'gdb' to debug 'gcc', and to set 'gcc''s command-line arguments (*note Arguments::) to '-O2 -c foo.c'.

You can run 'gdb' without printing the front material, which describes GDB's non-warranty, by specifying '-silent':

gdb -silent