gdb 使用

heeheeai

已于 2024-10-07 00:35:46 修改

阅读量651

点赞数 9

文章标签：开发语言 c++ gdb

于 2024-10-07 00:08:39 首次发布

本文链接：https://blog.csdn.net/heeheeai/article/details/142733938

版权

如果运行崩溃的程序后没有生成 core 文件，可以检查和调整以下几个设置：

确认 ulimit 设置允许生成 core 文件

通常，ulimit 控制生成 core 文件的大小。可以使用以下命令来检查当前的设置：

ulimit -c

如果输出为 0，表示 core 文件被禁用了。可以通过以下命令来允许生成 core 文件（即设置为不限制大小）：

ulimit -c unlimited

设置完后，可以再次运行程序，验证是否生成了 core 文件。

检查 core 文件生成位置

不同系统可能将 core 文件存放在不同的位置，或者有特定的命名规则。可以使用以下方法来检查 core 文件的生成位置和命名格式：

(a) 在 Linux 系统上

在大多数 Linux 发行版中，可以使用以下命令检查和设置 core 文件的生成路径和命名规则：

cat /proc/sys/kernel/core_pattern

输出可能类似于：

/var/lib/systemd/coredump/core.%e.%p.%h.%t

%e 表示可执行文件的名称。
%p 表示进程 ID。
%t 表示时间戳。
%h 表示主机名。

可以通过修改 /proc/sys/kernel/core_pattern 文件来更改生成 core 文件的路径和命名格式。例如，将 core 文件保存在当前目录下：

echo "core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern

(b) 在 macOS 系统上

macOS 默认不会生成 core 文件，但可以通过以下命令启用：

sudo launchctl limit core unlimited
ulimit -c unlimited

macOS 的 core 文件通常会保存在 /cores/ 目录中。

要配置 core 文件的生成目录，可以通过修改 /proc/sys/kernel/core_pattern 来实现。以下是具体步骤：

修改 core_pattern 来设置 core 文件生成目录

可以通过以下命令将 core 文件保存到指定目录，例如 /tmp/core_dumps/：

sudo mkdir -p /tmp/core_dumps  # 创建目录
sudo chmod 777 /tmp/core_dumps  # 设置权限，确保进程可以写入
echo "/tmp/core_dumps/core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern

在这里：

/tmp/core_dumps/ 是想要保存 core 文件的目录。
core.%e.%p 代表 core 文件的命名格式，其中 %e 是程序名称，%p 是进程 ID。

需要确保生成 core 文件的进程有写入该目录的权限。通常，将该目录权限设置为 777 是最简单的方法：

sudo chmod 777 /tmp/core_dumps

可选：永久保存 core_pattern 设置

如果希望在重启后保持 core 文件的生成路径，可以将上述命令加入系统启动脚本或配置文件。

在 Ubuntu/Debian 系统中

可以在 /etc/sysctl.conf 中添加以下行：

kernel.core_pattern=/tmp/core_dumps/core.%e.%p

然后运行以下命令使其生效：

sudo sysctl -p

在 RHEL/CentOS 系统中

可以在 /etc/sysctl.conf 中添加同样的行，然后执行：

sudo sysctl -p

或将 echo 命令添加到 /etc/rc.local，以确保系统启动时会自动应用：

echo "/tmp/core_dumps/core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern

检查修改是否生效

可以通过以下命令验证 core_pattern 是否被正确修改：

cat /proc/sys/kernel/core_pattern

输出应该显示设置的路径，例如：

/tmp/core_dumps/core.%e.%p

测试 core 文件生成

在配置完成后，运行可能崩溃的程序，或手动触发崩溃，查看指定目录中是否生成了 core 文件：

./crash_program
ls /tmp/core_dumps/

如果一切正常，将在 /tmp/core_dumps/ 中看到生成的 core 文件。

使用 GDB 调试 Core 文件和线程，并运行可执行文件的完整演示

以下演示将涵盖使用 GDB 调试 core 文件、调试多线程程序以及运行可执行文件的完整过程。

准备工作:

编写一个会产生 core dump 的 C 程序 (test.c):

#include <stdio.h>
#include <pthread.h>
#include <unistd.h>

void *thread_func(void *arg) {
int *p = NULL;
*p = 10; // 故意造成段错误
return NULL;
}

int main() {
pthread_t tid;
pthread_create(&tid, NULL, thread_func, NULL);
pthread_join(tid, NULL);
return 0;
}
编译程序并运行，产生 core dump 文件:

gcc -g -pthread test.c -o test
./test

使用 GDB 调试 core 文件:

gdb test core
查看程序崩溃信息:

(gdb) bt

这将显示程序崩溃时的调用栈信息，帮助定位到错误代码行。

查看崩溃线程的信息:

(gdb) info threads

这会列出程序中所有线程的信息，包括线程 ID 和当前状态。

切换到崩溃线程:

(gdb) thread <线程ID>

将 <线程ID> 替换为崩溃线程的 ID。

查看崩溃线程的局部变量和寄存器信息:

(gdb) frame 0
(gdb) info locals
(gdb) info registers
运行可执行文件并设置断点:

gdb test
(gdb) break main
(gdb) run

程序会在 main 函数处停止。

单步调试:

(gdb) next
(gdb) step

next 命令执行下一行代码，step 命令进入函数调用。

查看变量值:

(gdb) print <变量名>
继续执行程序:

(gdb) continue

程序会继续执行，直到遇到下一个断点或程序结束。

退出 GDB:

(gdb) quit

在 GDB 中连接正在运行的程序

可以使用 GDB 的 attach 命令将 GDB 附加到一个正在运行的进程。这样就可以在不重新启动程序的情况下进行调试。

操作步骤:

查找进程 ID:
使用 ps 命令或其他工具找到要附加的进程的 ID (PID)。例如:
ps aux | grep myprogram
启动 GDB:
gdb
附加到进程:
在 GDB 中使用 attach 命令，后面跟着进程 ID:
(gdb) attach
中断程序:
GDB 会自动中断程序的执行。可以使用 continue 命令让程序继续运行。
调试程序:
现在可以像往常一样使用 GDB 的命令来调试程序，例如设置断点、查看变量、单步执行等等。

示例:

假设要调试一个名为 myprogram 的正在运行的程序，它的 PID 是 12345。可以使用以下命令将 GDB 附加到该程序:

gdb
(gdb) attach 12345
Attaching to process 12345
Reading symbols from myprogram...
(gdb)

注意:

需要有足够的权限才能附加到一个进程。通常情况下，需要是该进程的所有者或者 root 用户。
附加到一个进程后，GDB 会中断该进程的执行。可以使用 continue 命令让程序继续运行。
如果想在程序启动时就进行调试，可以使用 gdb myprogram 命令启动程序，而不是 attach 命令。

通过 attach 命令，可以方便地调试正在运行的程序，而无需重新启动它，这在分析线上问题或调试难以复现的 bug 时非常有用。

假设场景:

有一个名为 myprogram 的 C++ 程序正在运行，它包含一个无限循环，每隔一秒钟打印一次当前时间。想使用 GDB 调试这个程序，查看循环内部的变量值。

操作步骤:

编译程序 (开启调试信息):
g++ -g myprogram.cpp -o myprogram -lpthread
运行程序:
./myprogram
查找进程 ID:
ps aux | grep myprogram
假设进程 ID 是 12345.
启动 GDB:
gdb
附加到进程:
(gdb) attach 12345
Attaching to process 12345
Reading symbols from myprogram…
(gdb)
中断程序:
GDB 会自动中断程序的执行。
设置断点:
假设我们想在 myprogram.cpp 文件的第 10 行设置一个断点:
(gdb) break myprogram.cpp:10
Breakpoint 1 at 0x401176: file myprogram.cpp, line 10.
继续执行程序:
(gdb) continue
Continuing.
程序中断在断点处:
当程序执行到第 10 行时，GDB 会再次中断程序。
查看变量值:
假设程序中有一个名为 counter 的变量，我们可以查看它的值:
(gdb) print counter
$1 = 5
单步执行:
可以使用 next 命令单步执行程序:
(gdb) next
继续执行或退出:
可以使用 continue 命令继续执行程序，或者使用 quit 命令退出 GDB。

完整示例 (myprogram.cpp):

#include <iostream>
#include <chrono>
#include <thread>

int main() {
  int counter = 0;
  while (true) {
    std::this_thread::sleep_for(std::chrono::seconds(1));
    counter++;
    std::cout << "Current time: " << time(nullptr) << std::endl; // 假设断点设置在这一行 (第 10 行)
  }
  return 0;
}

在 GDB 中，-p 和 attach 都用于连接到正在运行的进程，但它们有一些关键区别：

-p

启动并连接: -p 选项会在启动 GDB 的同时，立即连接到指定的进程 ID (PID)。
无法重新连接: 如果 GDB 因为某种原因与进程断开连接（例如程序崩溃），使用 -p 启动的 GDB 会直接退出，无法重新连接到该进程。

attach

先启动，后连接: attach 命令是在 GDB 已经启动后，手动连接到指定的进程。
可以重新连接: 如果 GDB 与进程断开连接，可以使用 attach 重新连接到同一个进程。
更多灵活性: 在使用 attach 连接到进程后，可以先进行一些设置（例如加载符号表），然后再中断程序的执行。

总结:

特性 -p attach
连接时机 GDB 启动时 GDB 启动后
断开连接后 GDB 退出可以重新连接
灵活性较低较高

选择建议:

如果需要在程序启动后立即开始调试，并且不需要担心断开连接的问题，可以使用 -p。
如果需要在程序运行一段时间后再进行调试，或者需要更高的灵活性，可以使用 attach。

希望以上解释能够帮助您理解 -p 和 attach 的区别！

好的，以下是使用 GDB 在程序已经在运行的情况下打断点的步骤：

找到程序的进程 ID (PID)

使用 ps aux | grep <程序名> 命令查找程序的进程 ID。
例如，如果的程序名为 myprogram，可以使用 ps aux | grep myprogram 查找。

启动 GDB 并连接到进程

使用 gdb -p 命令启动 GDB 并连接到程序进程。
例如，如果程序的 PID 是 1234，则可以使用 gdb -p 1234。

中断程序的执行

在 GDB 中，按下 Ctrl+C 中断程序的执行。

设置断点

使用以下命令设置断点：
- break <函数名>：在指定函数的入口处设置断点。
- break <文件名>:<行号>：在指定文件的指定行号设置断点。
- 例如，要在 main 函数设置断点，可以使用 break main；要在 myprogram.c 文件的第 10 行设置断点，可以使用 break myprogram.c:10。

继续程序执行

输入 continue 或 c 命令，让程序继续执行，直到遇到断点。

示例

假设的程序名为 myprogram，PID 为 1234，想在 main 函数设置断点：

ps aux | grep myprogram (找到 PID)
gdb -p 1234 (连接到进程)
Ctrl+C (中断程序)
break main (设置断点)
c (继续执行)

当程序执行到 main 函数时，GDB 会中断程序的执行，并显示当前的程序状态，就可以开始调试了。

注意

确保拥有调试程序的权限。
如果程序使用了反调试技术，可能无法使用 GDB 进行调试。
连接到正在运行的程序时，程序的状态可能已经发生了变化，因此设置断点的位置需要谨慎选择。

停止程序执行（可选）

如果程序已经在 gdb 中运行，并且想要添加新的断点，可以通过以下命令暂停程序的运行：

Ctrl + C

按下 Ctrl + C 会暂停程序的执行，并将带回 gdb 的调试提示符。

添加新的断点

在暂停后，使用 break 命令来添加新的断点。可以按以下方式设置断点：

在某个文件的指定行号设置断点：
break filename:line_number
例如，在文件 main.c 的第 42 行设置断点：
break main.c:42
在某个函数上设置断点：
break function_name
例如，在函数 my_function 的入口处设置断点：
break my_function
在指定地址处设置断点：
break *0xaddress
例如，在内存地址 0x08048456 处设置断点：
break *0x08048456

恢复程序执行

添加完新的断点后，可以让程序继续运行，使用 continue 命令：

continue

gdb 会让程序继续执行，直到程序遇到新设置的断点或其他异常情况。

列出所有断点

可以使用 info breakpoints 命令来列出所有当前设置的断点：

info breakpoints

这会显示所有断点的信息，包括断点编号、位置、使能状态等。

删除断点（可选）

如果想删除一个断点，可以使用 delete 命令，后面跟上断点编号：

delete breakpoint_number

例如，删除编号为 1 的断点：

delete 1

示例

假设已经通过 gdb 启动了程序，并且正在调试某个文件。在调试时，决定在文件 example.c 的第 50 行设置一个新的断点。步骤如下：

暂停程序：按 Ctrl + C。
设置断点：
break example.c:50
继续运行：
continue

程序将在 example.c 的第 50 行暂停，可以开始调试这个位置的代码

启用 Pretty Printer

Pretty Printer 是一种让 gdb 更加智能地打印复杂 C++ 对象（特别是 STL 容器）的方法。以下步骤说明如何确保它启用：

对于 GCC 编译的程序（使用 libstdc++）

默认支持：如果使用的是现代版本的 GCC，Pretty Printer 应该是默认启用的。
可以检查 Pretty Printer 是否启用，运行：
info pretty-printer
如果 Pretty Printer 列在输出中，则表明它已经启用。
手动启用：如果没有启用，或者想手动加载 Pretty Printer，通常 libstdc++ 的 Pretty Printer 文件在的系统中位于类似的路径：
/usr/share/gcc-/python/libstdcxx/v6/printers.py
在 .gdbinit 中可以添加以下代码来启用 Pretty Printer：
python
import sys
sys.path.insert(0, ‘/usr/share/gcc-/python’)
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers(gdb.current_objfile())
end

对于 Clang 编译的程序（使用 libc++）

libc++ 也有对应的 Pretty Printer，需要类似的设置。安装 libc++ 的 Python Pretty Printer 并按照类似的步骤在 gdb 中启用它。

打印 STL 容器

启用 Pretty Printer 后，gdb 会自动格式化并打印 STL 容器，下面是一些常用容器的打印方法：

打印 std::vector

假设有一个 std::vector 变量 my_vector，可以在 gdb 中打印其内容：

print my_vector

如果 Pretty Printer 正常工作，会看到类似以下的输出：

$1 = std::vector of length 3 = {1, 2, 3}

打印 std::map

对于 std::map<int, std::string>，同样可以使用 print 命令：

print my_map

输出可能是这样的：

$2 = std::map with 2 elements = {[1] = "one", [2] = "two"}

打印 std::list

对于 std::list，命令如下：

print my_list

输出可能是这样的：

$3 = std::list of length 4 = {1, 2, 3, 4}

打印 std::set

对于 std::setstd::string，命令如下：

print my_set

输出可能是这样的：

$4 = std::set of length 3 = {"apple", "banana", "cherry"}

打印 STL 容器的单个元素

有时可能只想查看容器中的某个特定元素。可以使用索引或迭代器来打印单个元素。

打印 std::vector 中的某个元素

print my_vector[0]

这将输出 my_vector 中第一个元素的值。

打印 std::map 中的键值对

要查看 std::map 中某个具体的键值对，可以先获取迭代器：

print my_map.begin()

然后打印出迭代器指向的键值对：

print *my_map.begin()

输出可能是这样的：

$5 = std::pair<int, std::string> = {1, "one"}

打印迭代器

如果想手动遍历 STL 容器，可以使用迭代器。以下是如何使用迭代器来遍历 std::map 的示例：

set iter = my_map.begin()      # 获取迭代器
print *iter                    # 打印当前迭代器位置的值
set iter = ++iter              # 移动到下一个元素
print *iter                    # 打印下一个元素

这种方法适用于所有支持迭代的 STL 容器。

列出容器内容（例如 vector 所有元素）

可以通过以下方式打印 std::vector 中所有元素的值：

print my_vector@size

其中，size 是 vector 的大小。例如：

print my_vector@10

如果 my_vector 的大小为 10，这将打印出所有 10 个元素。

如果 Pretty Printer 不工作

如果 Pretty Printer 没有生效，gdb 可能只会显示 STL 容器的内部数据结构。可以尝试打印容器的内部指针和其他字段来手动提取数据，但这种方法会更加繁琐。例如：

print my_vector._M_impl._M_start[0]  # 访问 vector 的第一个元素

具体字段名称可能会因 C++ 标准库的实现而有所不同。

在使用 gdb 调试时，可以通过以下几种方式查看某个断点附近的代码，即使可能没有完整的源代码。下面是一些有效的方法：

查看源代码上下文（如果可用）

如果可执行文件是用调试信息编译的（即没有完全剥离符号），可以直接查看断点处附近的源代码。

方法：使用 list 命令

list 命令可以显示断点或当前执行点附近的源代码。

显示断点所在位置的代码：
list <breakpoint_location>
例如，如果在 main 函数上设置了断点，可以使用：
list main
或者，如果断点是在某个行号处，可以使用：
list :<line_number>
显示当前执行点附近的代码：
list
这会显示当前执行位置附近的源代码。

查看汇编代码

如果没有源代码信息（比如符号被剥离），可以查看断点处的汇编代码。

方法：使用 disassemble 命令

disassemble 可以显示某个函数或地址附近的汇编代码。

查看当前函数的汇编代码：
disassemble
这会显示当前正在执行的函数的汇编代码。
查看指定函数的汇编代码：
disassemble <function_name>
例如，如果断点在 main 函数，可以这样查看：
disassemble main
查看特定内存地址附近的汇编代码：
disassemble 0x

例如，可以指定某个断点处的地址来查看该位置的汇编代码。

设置断点时立即显示附近的代码

当设置了一个断点后，gdb 可以直接显示该断点处的代码。可以使用以下命令设置断点并查看该位置附近的代码：

设置断点并显示源代码：
break <function_name> if available
或者：
break :<line_number>
当程序运行到这个断点时，使用 list 或 disassemble 查看该位置附近的代码。

打印当前执行位置附近的代码

当在调试过程中命中断点时，可以使用 gdb 的以下命令来查看当前程序的执行位置：

查看断点命中处的代码或内存地址：
info breakpoints
然后使用断点地址来反汇编，或者使用 list 命令查看该位置的源代码。

使用 x 命令查看内存

如果想手动查看某个内存地址处的原始数据，可以使用 x 命令来查看内存。x 命令允许以多种格式查看指定地址附近的数据。

例如，要查看一个断点附近的 10 条汇编指令，可以使用：

x/10i $pc

其中 $pc 是当前程序计数器寄存器，表示当前指令的位置。10i 表示显示 10 条汇编指令。

还可以指定内存地址，比如：

x/10i 0x<address>

这会显示从该内存地址开始的 10 条汇编指令。

检查符号信息

首先，在调试生产级别的可执行文件时，检查符号表的情况非常重要。生产环境中的可执行文件通常被剥离了调试符号（通过 strip 命令）。可以使用以下命令检查符号表是否还存在一些符号信息：

nm <executable>

如果符号已经被移除（剥离），输出将非常有限。

载入可执行文件

启动 gdb 并加载可执行文件：

gdb <your_executable>

加载后，可以通过以下命令列出可用的函数符号：

info functions

如果有可用的符号，gdb 会显示所有函数和它们的地址。即使没有完整的调试信息，您也可能会看到某些全局函数和库函数。

设置断点

尽管可能没有调试符号，但仍然可以在已知的函数上设置断点，甚至可以直接在内存地址上设置断点：

通过函数名设置断点：

break <function_name>

例如：

break main

通过内存地址设置断点：

break *0x<address>

要获取函数的地址，可以通过 info functions 或 nm 来找到。

反汇编代码

由于生产环境中的可执行文件很可能已经被编译并优化，源代码与汇编代码可能有很大的区别。可以使用 disassemble 命令查看当前函数或内存地址的汇编代码：

反汇编当前执行的函数：

disassemble

反汇编特定函数：

disassemble <function_name>

例如：

disassemble main

反汇编内存地址范围：

disassemble 0x<start_address>, 0x<end_address>

这将显示该地址范围内的汇编代码。

单步执行

在没有源代码的情况下，gdb 允许在汇编级别逐步执行程序。可以使用以下命令逐步调试程序：

逐步执行汇编指令：

stepi

此命令将逐条执行汇编指令。

继续执行到下一个断点：

continue

查看寄存器和内存

在调试优化后的生产环境可执行文件时，寄存器和内存内容的检查非常关键。可以使用以下命令查看当前 CPU 寄存器的值：

info registers

此外，gdb 允许检查内存中的内容。可以使用 x 命令以不同格式查看内存：

x/<format> <address>

例如：

x/10x 0x7fffffffe000

这将显示从 0x7fffffffe000 开始的 10 个单位的内存内容，格式为十六进制。

还可以检查具体变量所在的内存地址（如果知道其地址）：

print *(int*)0x<address>

使用堆栈跟踪

即使是优化的可执行文件，调用栈信息仍然可以帮助理解程序的执行流程。可以使用 backtrace 命令来查看调用栈：

backtrace

这将显示当前线程的调用栈，包括每个函数的符号和返回地址。尽管由于优化，堆栈信息可能会有所损坏或不完整，但这通常是调试的一个很有用的步骤。

查找内存中的字符串

在生产环境中，有时候通过搜索内存中的已知字符串或某些特殊的常量可能会帮助理解程序的运行状态。可以使用以下命令搜索内存中的字符串：

find 0x<start_address>, 0x<end_address>, "<string>"

例如，如果想在某个地址范围内搜索字符串 hello：

find 0x400000, 0x500000, "hello"

调试共享库

如果的可执行文件依赖于共享库（如 .so 文件），可以使用 info sharedlibrary 命令查看哪些共享库已加载并找到它们的加载地址。还可以在这些库中的函数上设置断点：

info sharedlibrary
break <shared_lib_function>

利用优化信息

生产环境中的可执行文件往往经过编译器优化。优化可能会导致函数被内联、循环展开、变量被寄存器化等。因此，在调试时会发现一些变量或函数似乎消失了。这是正常的，因为优化会改变代码的布局和执行流程。可以通过以下方式减少优化对调试的影响：

在 gdb 中，使用 set disable-randomization on 来禁用地址空间布局随机化 (ASLR)，以确保可重现的调试环境。
检查并理解优化后的代码布局和可能的内联函数。使用反汇编 (disassemble) 结合寄存器和内存检查命令理解优化后的代码。

使用 core dump 文件

如果程序在生产环境中崩溃，可以生成 core dump 文件并使用 gdb 对其进行调试。通过以下方式启动 gdb 并加载 core dump：

gdb <your_executable> core

然后可以使用类似前述的命令，如 backtrace、info registers、disassemble 等来调试 core dump 文件中的崩溃现场。

调试一个带有调试信息的可执行程序（通常是通过使用 -g 选项编译的）可以为提供详细的源代码、变量、函数名等信息，使得调试更加高效。以下是调试一个带有调试信息的可执行程序时的常见操作步骤和命令。

编译可执行文件带调试信息

在调试之前，需要确保可执行文件包含调试信息。这通常是通过在编译时添加 -g 选项完成的。例如：

gcc -g -o my_program my_program.c

或对于 C++ 程序：

g++ -g -o my_program my_program.cpp

这个选项会使编译器将调试符号保留在生成的可执行文件中，方便 gdb 调试。

启动 GDB

要调试程序，首先通过 gdb 启动它：

gdb my_program

这会启动 gdb 并加载的可执行文件。

运行程序

可以使用 run 命令启动程序。如果程序需要参数，可以直接在 run 后面传入：

run [program_arguments]

例如：

run arg1 arg2

设置断点

在 gdb 中，可以通过 break 命令在源代码中的函数、文件或者行号处设置断点。

在某个函数的入口处设置断点：
break main
在指定的文件行号设置断点：
break my_program.c:20
在特定条件下设置断点：
break my_program.c:20 if x == 5
打印所有断点：
info breakpoints

单步执行代码

当程序运行到断点时，可以使用以下命令来逐步调试程序：

next (n): 单步执行代码，跳过函数调用。每次执行一行代码。
next
step (s): 单步执行代码，但会进入函数调用内部。如果当前行有函数调用，step 会进入函数体内。
step
finish: 执行当前函数直到返回。
finish
until: 执行代码直到指定行号或程序当前位置之后。
until <line_number>

查看变量

gdb 提供多种方式来查看程序的状态，包括当前的局部变量、全局变量、内存等。

print §: 打印变量的值。例如：
print x
display: 设置某个变量的自动显示，即每当程序暂停时自动打印该变量的值。
display x
info locals: 显示当前函数中的所有局部变量及其值。
info locals
info args: 显示当前函数的所有参数。
info args

调用栈

gdb 可以显示当前程序调用栈的状态，帮助了解程序是如何运行到当前位置的。

backtrace (bt): 显示当前调用栈。如果程序正在深度调用多个函数，这个命令会列出所有函数调用信息。
backtrace
frame (f): 切换到调用栈的某一帧。例如，如果想切换到上一级函数的调用帧：
frame 1

修改变量值

可以在调试过程中修改变量的值：

set: 修改变量的值。例如：
set var x = 10

这对调试程序的逻辑错误非常有用，允许实时修改程序状态并观察其影响。

查看源代码

gdb 提供了一些命令来查看源代码：

list (l): 查看当前执行点附近的源代码。默认会显示当前行的前后几行。
list
指定函数或行号来查看代码：
list main
list my_program.c:20

检查汇编代码

在某些情况下，可能需要查看程序的汇编代码。

disassemble: 显示当前函数的汇编代码：
disassemble
显示某个函数或内存地址的汇编代码：
disassemble main
disassemble 0x4005f4

调试运行时崩溃的程序

如果程序由于段错误（Segmentation Fault）崩溃了，gdb 可以帮助找到问题。

运行程序直到崩溃，然后使用 bt 命令查看崩溃时的调用栈：
run
backtrace

退出 GDB

调试结束后，可以使用以下命令退出：

quit

使用 gdb 修改变量值时，程序需要暂停。当程序在运行时，无法直接修改变量的值。必须让程序进入暂停状态，例如通过断点、单步调试或者手动暂停，然后才可以修改变量的值。

以下是让程序暂停的几种方式：

断点（Breakpoint）：
设置一个断点，当程序运行到某个特定位置时自动暂停。例如，设置断点在某行：
break <line_number>
当程序运行到这个行时，会自动暂停，可以此时修改变量的值。
手动暂停：
如果程序已经在运行，可以使用以下命令暂停：
Ctrl + C
这会强制程序暂停，此时可以在 gdb 中执行命令来修改变量。
单步调试（Step through the code）：
使用 gdb 的单步调试功能，逐行执行程序。在每执行完一行时，程序会暂停等待的指令。
- step：逐行执行代码，包括进入函数内部。
- next：逐行执行代码，但不会进入函数内部。
  每次暂停时，都可以修改变量的值。

具体步骤：