GDB Debugger Usage Summary

Overview:GDB is a Linux debugging program artifact, as a Linux programmer, if you can not skillfully use GDB for program debugging, it will be a failure. The powerful function makes GDB's use also become more complicated, if is beginner certainly will be frightened by the complicated command. Here are some of the things I think would be helpful. The command starting with ">" Below is the shell command for Linux, and the GDB internal command begins with "(GDB)".

0. Dump function (Core dump):

(1). Turn on the dump function:First use >ULIMIT-C to see if the dump function is turned on, if the command returned is not 0 is turned on, otherwise it is not turned on. The >ulimit-c Unlimited command can turn on the dump function. You can also use >ulimit-c 1024来 to set the size of the dump file. (2). Set dump file generation address:Edit the/etc/sysctl.conf file and add the following two lines at the end of the file:        Kernel.core_pattern =/var/core/%t-%e-%p.core        Kernel.core_uses_pid = 0    Then save the file and execute it after the save is complete: >sysctl-p command (note: Root is required to execute this command.) ）。 At this point, a program that will run as a machine generates a dump file (for example: 1432378356-a.out-4821.core) under the/var/core/folder. The file name set above is a fixed format, the Core_pattern is set to save the directory and file name format. Where%t is the Unix timestamp at the time of the dump,%e is the currently executing file name, and%p is the PID of the crash process. The format characters are described as follows:

%p

format symbol
%%	% character itself
%u
%g	True group of dumped processes (GID)
%s
%t	dump time, Unix timestamp (number of seconds from January 1, 1970 0 o'clock)
%h	host name
%e	executable name
%c

(3). Compression of dump files:The resulting dump file can be compressed by adding a compression script and a pipe command to the Core_pattern of the/etc/sysctl.conf file. First add the following two lines in the/etc/sysctl.conf file (modified to the following form if they already exist): Kernel.core_pattern = |/usr/localsbin/zipsh%t%e%p kernel.c    Ore_uses_pid = 0 Save the file, and then execute the: >sysctl-p command. The contents of the/usr/local/sbin/zipsh file are as follows: #!/bin/sh exec gzip->/var/core/$1-$2-$3.core.gz In this case, it will be born in/var/core. The compressed dump file.
1. Basic Information View: (1). Stack information:Whether you are manipulating a dump file or debugging with a GDB set breakpoint, you can enter (GDB) to view the contents of the BT print stack. General when the machine bug, look at the location of the machine, and then look at the source code basic can be solved. However, in many cases the simple (GDB) bt still does not find the problem, this time will involve more complex operations.        Here are some of the operations on the stack: (GDB) bt: Displays all stack frames.        (GDB) bt 10: Displays the previous 10 stack frames.        (GDB) Bt-10: Shows the next 10 stack frames.        (GDB) bt full: Displays stack frames and local variables.        (GDB) bt full 10: Displays the previous 10 stack frames and local variables.        (GDB) bt full-10: Shows the next 10 stack frames and local variables.        (GDB) frame < stack frames;: Enter the specified stack frame, and then you can view the local variables in the current stack frame, as well as information such as the contents of the stack frame.        (GDB) Info Frame < stack frame number;: You can view detailed information for the specified stack frame.        (GDB) Up: Enter the upper stack frame. (GDB) Down: Enter the lower stack frame. (2). Variables:Viewing variable information during the debugging of a bug is a helpful way to see the following: (GDB) p < variable name > (3). Register:For debugging, the value in the register is also important, you can see the address of the currently executing instruction, and so on. The specific operation is listed as follows: (GDB) Info reg: Displays all registers. can be abbreviated as: I R.        If you want to see a specific register you can do this: I $ebx (GDB) P $eax: Displays the contents of the EAX register. (GDB) p/c $eax: Displays the contents of the EAX register in characters, followed by a display format, which can be used in the following table: The table is also common in the X command that displays memory content.

d

format
x
displayed as decimal number
u
o
t
a	Show as ground Address
c
f
s
i

(4). Memory:You can view the contents of a specific memory address, such as the currently executing assembly instructions, as well as the contents of the stack.        (GDB) x $pc: Displays the contents of the position that the program pointer points to.        (GDB) x/i $pc: Displays assembly instructions for the current location of the program.        (GDB) x/10i $pc: Shows the 10 assembly instructions that begin at the beginning of the current position of the program. (GDB) Disassem $pc: Disassembly of the current function. Abbreviated as: Disas $pc. 2. Commissioning: (1). Breakpoint:debugging programs, setting breakpoints for debugging is the most convenient and effective means, so learn if the flexibility to set breakpoints is the basic of debugging. ： A. Set Breakpoints:(GDB) Break < function name;: Sets a breakpoint on the specified function in the currently executing file. can be abbreviated as: (GDB) b < function name > (GDB) Break < line number;: Sets a breakpoint on a specific line in the currently executing file. Abbreviated to: (GDB) b < line number > (gdb) Break < file name: line number;: Sets a breakpoint on the specified line of the specified file. The most common way to set breakpoints. Abbreviated as: (GDB) b < file name: line number > (gdb) Break < file name: function name;: Sets a breakpoint on the specified function for the specified file. The methods in the C + + class do not seem to be so. Abbreviated to: (GDB) b < file name: function name > (GDB) Break <+/-offset;: The current command line +/-offsets the set breakpoint. can be abbreviated as: B <+/-offset > (GDB) Break <* address;: Set breakpoint at the specified address. can be abbreviated as: B <* address > B. View and delete breakpoints:(GDB) Info break: Displays all breakpoints and monitoring points. can be abbreviated as: (GDB) I B (gdb) Delete < number;: Delete the breakpoint or watch point that the number points to.            can be abbreviated as: (GDB) d < numbering > (GDB) Clear < line number;: Delete the breakpoint of the row. (GDB) Clear < file name: line number;: Delete the breakpoint for the row. C. Set invalid, valid breakpoint:(GDB) Disable < Breakpoint number >: The current breakpoint is set to invalid. (GDB) Enable < breakpoint number;: The current breakpoint is set to valid. (2). Monitoring point:A variable can be monitored, and the program enters a breakpoint at the current point when the variable is accessed or modified. Delete, and view the monitor point the same way as the breakpoint.        Set the monitoring point as follows: (GDB) Watch < expression;: Pause when the expression changes.        (GDB) Awatch < expression;: Pause when an expression is accessed or changed. (GDB) Rwatch < expression;: Pause when the expression is accessed. (3). Conditional breakpoint:In the process of debugging, sometimes we just want to stop the program under a certain condition, and then do one-step debugging, and the conditional breakpoint is designed for this. Here's how conditional breakpoints work: (GDB) b < breakpoints > If < conditional expressions >: For example: B main.cpp:8 if x=10 && y=10 (gdb) Condit        Ion < breakpoint number;: Delete the breakpoint's condition. (GDB) Condition < breakpoint number > < conditional expression;: Modify the breakpoint condition. Example: Condition 1 x=10 && y=10 (4). Breakpoint Command:Every time a breakpoint occurs, there are a lot of variables to look at, and if each variable is manually print it will take a lot of time. The breakpoint command can execute the GDB command in bulk when a breakpoint occurs.        Here's how the breakpoint command is set up: (GDB) Commands < breakpoint number > (GDB) >print x (gdb) >print y (gdb) >end First enter the GDB command commands < breakpoint number > then enter, this time the > prompt appears. When the > prompt appears, you can enter the GDB command to execute when a breakpoint occurs, one per line, and the end Breakpoint command after all input is completed. (5). Repeated execution:When stepping into a function that you do not care about, you want to jump out of the function immediately, or into the cycle, you want to loop immediately.        The following command can help you: (GDB) Ignore < breakpoint number > < times;: Ignores n breakpoints.        (GDB) C N: Executes the n-th instruction, ignoring the breakpoint.        (GDB) S/stepi/n/nexti N: Executes n rows backwards, without ignoring breakpoints.        (GDB) Finish: Stops after executing the current function and does not ignore breakpoints.        (GDB) Until: stops after the current loop is executed, and the breakpoint is not ignored. (GDB) until < address: execution to the specified address stop. (6). Set the value of the variable:Control the value of the variable, you can debug your own program faster. Here's how to set the value of a variable: (GDB) Set Variable < variables > = < expression;: Sets the value of the variable to the value of the specified expression. For example Set Variable x=10 (7). Manually generate the dump file:(GDB) Generate-core-file shorthand for: (GDB) Gcore 3. Debug the online process: (1). Link the target process when GDB is started:When you start GDB, you can enter the debug state by specifying the target process with the parameter-P. Just after the link is successful, the program is paused, you can set breakpoints and so on, and the input (GDB) C command continues to run. The command is as follows: >gdb-p <pid>:pid is the process ID and can be >ps aux | grep < program name > get. or directly >gdb-p ' pidof < program name > ' can also. >pidof < Program name > is the command that gets the process ID by name. (2). GDB links the target process:(GDB) Attach <PID> (3). Break Link:(GDB) Detach 4. Debug Multi-threaded threads: (1). View Threads:(GDB) Info thread: View all thread information, abbreviated as: I THR (2). Switch to the specified thread:(GDB) thread < thread number;: Select the thread that is in question, abbreviated to: THR < thread number > (3). Debug Daemon Process:The daemon process automatically shuts down the main process after the child process is started, and if no monitoring mode is set, GDB will prompt you to break the link to the process. Therefore, the monitoring object must be set up as follows: (GDB) Set Follow-fork-mode child/parent

GDB Debugger Usage Summary