Seven or eight years ago I wrote an article called “Debugging programs with GDB”. Since then, many friends have emailed me and asked me questions about GDB on MSN. Still today, people are asking me questions about GDB. Over the years, there are some questions that you have repeatedly asked. On the one hand, I think my previous articles may not be clear, and on the other hand, I think the questions you often ask are the most useful, so I list them here. I want you to add.

First, multithreading debugging

Multithreaded debugging is probably the most asked question. In fact, the following commands are important:

  • Info thread Displays the thread of the current process.
  • Thread

    Switches the debugging thread to the thread with the specified ID.
  • Break file.c:100 thread All Sets a breakpoint at line 100 of file.c for all threads passing through.
  • Set the scheduler – locking off | on | step, this is the most frequently asked. When debugging the current thread with step or continue commands, other threads are also executing at the same time. This requirement can be implemented with this command.
    • Off does not lock any threads, meaning that all threads execute, which is the default.
    • On Only the program currently being debugged will execute.
    • When step steps, only the current thread executes, except when next passes a function (which, as those familiar with the situation may know, is a breakpoint set and then continue).

Debug macros

That’s a lot of questions. Under GDB, we cannot print the macro definition because the macro is precompiled. But there is a way to debug macros, and this requires GCC.

When compiling GCC, add the -ggdb3 parameter, so that you can debug macros.

In addition, you can use the following GDB macro debugging command to view the relevant macros.

  • Info Macro – You can see in which files the macro is referenced and what the macro definition is.
  • Macro – You can see how the macro expands.

Call waiting welfare

1. Recently sorted out 20G resources, including product/operation/test/programmer/market, etc., and Internet practitioners [necessary skills for work, professional books on the industry, precious books on interview questions, etc.]. Access:

  • Scan the code of wechat to follow the public account “Atypical Internet”, forward the article to the moments of friends, and send the screenshots to the background of the public account to obtain dry goods resources links;

2. Internet Communication Group:

  • Pay attention to the public account “atypical Internet”, in the background of the public account reply “into the group”, network sharing, communication;

3. Source files


This question is also a lot of, too many friends say can not find the source file. Here I would like to remind you to do the following checks:

  1. Whether the compiler added the -g parameter to contain the debug information.
  2. Verify that the path is set correctly. Use the directory command of GDB to set the directory of the source file.

Here is an example of debugging /bin/ls (ubuntu)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ apt-get
source
coreutils
$
sudo
apt-get
install
coreutils-dbgsym
$
gdb
/bin/ls
GNU
gdb
7.1 the ubuntu (GDB)
(
gdb
) list main
1192
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 main
1192}
1193}
1194
1195 int
1196 main (int argc, char **argv)
1197 {
1198 int i;
1199 struct pending *thispend;
1200 int n_files;
1201

Conditional breakpoints

Conditional breakpoints are syntax: break [where] if [condition]. Especially if you’re in a loop or recursion, or if you’re monitoring a variable. Note that this setting is in GDB, but GDB checks for you every time you pass that breakpoint.

Command line parameters

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

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

Vi. Variables of GDB

Sometimes, when debugging a program, we don’t just look at variables at run time. We can also set variables directly in the program to simulate conditions that are difficult to test, compare errors, or branch statements of the switch. Use the set command to modify variables in a program.

Also, did you know that you can have variables in GDB? Like a shell, variables in GDB start with $. For example, if you want to print each element in an array, you can do this:

1
2
3
4
5
(
gdb
)
set
$i = 0
(
gdb
) p a[$i++]
.
# And went straight back to the car

Of course, this is just an example of how variables representing programs and GDB can interact.

X command

Maybe you enjoy using the P command. So, when you don’t know the variable name, you might be confused, because the p command always needs a variable name. The x command is used to view memory, and you can see the help in GDB under “help x”.

  • X /x is output in hexadecimal format
  • X /d is printed in decimal notation
  • X /c is printed as a single character
  • X/I disassembly – usually, we useX /10i $ip-20 to view the current assembly
  • X /s is printed as a string

A. command B. command C. command D. command

Some friends asked me how to automate debugging. GDB is a package of GDB commands, sort of like a word processor “macro”. Here is an example:

1
2
3
4
5
6
7
8
9
10
(
gdb
)
break
func
Breakpoint 1 at 0x3475678:
file
test
.c, line 12.
(
gdb
)
command
1
Type 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 is reached, the three commands in command are automatically executed, typing out the three parameters of func.

(Full text)

Author: increasingly, blog: https://coolshell.cn/articles/18190.html