Several debugging methods that should be known in gdb come from Chenhao

Several debugging methods that should be known in GDBFebruary 10, 2011 Chenhao Comment read review 62,325 people read

Seven or eight years ago wrote a "debugging program with GDB", so, since then, a lot of friends on MSN and sent me an e-mail to ask me about the problem of GDB, until today, there are people asking gdb related issues. Over the years, some questions have been asked repeatedly, on the one hand, I feel that my previous articles may not be clear, on the other hand, I think the questions that people often ask are the most useful, so, listed here. I hope you will add.

One, multi-threaded debugging

Multithreaded debugging may be the most frequently asked. In fact, the following commands are important:

• Info thread to view the threads of the current process.
• Thread <ID> Switches Debug threads to the specified ID of the thread.
• Break file.c:100 thread all sets a breakpoint on line 100th of the file.c file for all threads passing through here.
• Set Scheduler-locking Off|on|step, this is the most asked. When using the step or the continue command to debug the currently debugged thread, the other threads are executing simultaneously, so how do you just let the debugger execute it? This requirement can be achieved with this command.
  • Off does not lock any threads, that is, all threads are executed, which is the default value.
  • On only the currently debugged program will execute.
  • Step in a single step, in addition to the case of next over a function (the person familiar with the situation may know that this is actually a set breakpoint and then continue behavior), only when the front-thread will execute.

Second, debug macros

This problem is very much. Under GDB, we cannot print the macro definition because the macro is precompiled. But we still have a way to debug the macro, which requires GCC mates.

When you compile the program in GCC, add the -ggdb3 parameter so that you can debug the macro.

Alternatively, you can use the following GDB macro debugging commands to view the related macros.

• Info macro– you can see which files the macro is referenced in and what the macro definition is.
• macro– you can see what the macro expands to look like.

Third, the source file

This question is also a lot of questions, too many friends say the source files can not be found. Here I would like to remind you to do the following check:

1. Compiles whether the programmer added the-G parameter to contain the debug information.
2. The path is set correctly. Use the GDB Directory command to set the directory for the source files.

Below is an example of a debug/bin/ls (under Ubuntu)

1234567891011121314151617181920

$ apt-get source coreutils$ sudo apt-get install coreutils-dbgsym$ gdb /bin/lsGNU gdb (GDB) 7.1-ubuntu(gdb) list main1192    ls.c: No such file or directory.in ls.c(gdb) directory ~/src/coreutils-7.4/src/Source directories searched: /home/hchen/src/coreutils-7.4:$cdir:$cwd(gdb) list main1192        }1193    }11941195    int1196    main (int argc, char **argv)1197    {1198      int i;1199      struct pending *thispend;1200      int n_files;1201

Iv. Conditional Breakpoints

The conditional breakpoint is the syntax: Break [where] if [condition], this breakpoint really works. Especially in a loop or recursion, or to monitor a variable. Note that this setting is in gdb, except that GDB will help you check if the condition is satisfied every time you pass that breakpoint.

Five, command-line parameters

Sometimes, we need to debug the program need to have command line parameters, many friends do not know how to set the Debug program command line parameters. In fact, there are two ways:

1. GDB command-line –args parameter
2. The set args command in the GDB environment.

Vi. Variables for GDB

Sometimes, when debugging a program, we don't just look at runtime variables, we can also set variables directly in the program to simulate some of the things that are difficult to see in a test, to compare some errors, or to switch branch statements. Use the SET command to modify variables in a program.

Also, do you know that there can be variables in GDB? Just like the shell, the variables in GDB start with $, like you want to print an array of elements, you can do this:

12345

(gdb) set$i = 0 (gdb) p a[$i++]...  #然后就一路回车下去了

Of course, here is just an example, which indicates that the variables of the program and the GDB variables can be interacted with.

Seven, x command

Perhaps, you like to use the P command. Therefore, when you do not know the variable name, you may be unprepared, because the P command always requires a variable name. The x command is used to view the memory, and in GdB, "Help X" You can view its assistance.

• x/x with hexadecimal output
• X/D Output in decimal
• X/C output with single character
• X/i Disassembly – Typically, we will usex/10i $ip-20 来查看当前的汇编（$ip是指令寄存器）
• X/S output as a string

Viii. command Commands

Some friends asked me how to automate debugging. Here we introduce command command, simple understanding, it is a set of GDB command package, a bit like word processing software "macro." Here is an example:

12345678910

(gdb) break funcBreakpoint 1 at 0x3475678: file test.c, line 12.(gdb) command 1Type commands for when breakpoint 1 is hit, one per line.End with a line saying just "end".>print arg1>print arg2>print arg3>end(gdb)

When our breakpoint arrives, the three commands in the command are automatically executed, and the three parameter values of Func are called out.

--------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- ---------------------------------------------

GDB multithreaded debugging

Http://hi.baidu.com/hcq11/blog/item/9f5bfc6e696209d680cb4a25.html

Http://hi.baidu.com/litto/blog/item/759389dd198111375882dd1e.html

Http://blogold.chinaunix.net/u3/94700/showart_2389432.html < recommended reading >

First, we introduce the basic command of GDB multi-threaded debugging.

Info Threads shows all threads currently available for debugging, each with a GDB-assigned ID, which is used when the thread is being manipulated. Previous * is the thread that is currently being debugged.

The thread ID Toggles the currently debugged thread for the specified ID.

Break thread_test.c:123 Thread all sets a breakpoint on the corresponding line in all threads

thread apply ID1 ID2 command to have one or more threads execute GDB commands.

The thread apply all command lets all the debugged threads execute GDB command commands.

The set scheduler-locking off|on|step estimate is that anyone who has actually used multithreaded debugging can find that other threads are executing at the same time using the step or Continue command to debug the currently debugged thread. How do you just let the debugger execute it? This requirement can be achieved with this command. Off does not lock any threads, that is, all threads are executed, which is the default value. On only the currently debugged program will execute. Step in a single step, in addition to the case of next over a function (the person familiar with the situation may know that this is actually a set breakpoint and then continue behavior), only when the front-thread will execute.

GDB has the following support for debugging multi-threaded threads:

• Thread Generation Notification: GDB gives a hint when a new thread is generated

(GDB) R
Starting program:/root/thread
[New Thread 1073951360 (LWP 12900)]
[New Thread 1082342592 (LWP 12907)]---The following three new threads are created
[New Thread 1090731072 (LWP 12908)]
[New Thread 1099119552 (LWP 12909)]

• View Threads: Use info threads to view the threads that are running.

(GDB) Info threads
4 Thread 1099119552 (LWP 12940) 0xffffe002 in?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in?? ()
* 1 Thread 1073951360 (LWP 12931) Main (argc=1, argv=0xbfffda04) at thread.c:21
(GDB)

Note that the blue text at the beginning of the line is the thread number assigned by GDB, which is used when switching threads, instead of the green number indicated above.

In addition, the red asterisk at the beginning of the line identifies the currently active thread

• Toggle Thread: Use thread threadnumber to switch threadnumber to the thread number mentioned above. The following example shows switching the active thread from 1 to 4.

(GDB) Info threads
4 Thread 1099119552 (LWP 12940) 0xffffe002 in?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in?? ()
* 1 Thread 1073951360 (LWP 12931) Main (argc=1, argv=0xbfffda04) at thread.c:21
(GDB) Thread 4
[Switching to thread 4 (thread 1099119552 (LWP 12940)]) #0 0xffffe002 in?? ()
(GDB) Info threads
* 4 Thread 1099119552 (LWP 12940) 0xffffe002 in?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in?? ()
1 Thread 1073951360 (LWP 12931) Main (argc=1, argv=0xbfffda04) at thread.c:21
(GDB)

The following is directly in your thread function to set a breakpoint, and then continue to that breakpoint, generally multi-threaded, because it is running at the same time, it is best to set scheduler-locking on

In this case, only the current thread is debugged

Category: C/C + + Tags: debug, gdb, Thread

Several debugging methods that should be known in gdb come from Chenhao