GDB-调试正在运行程序和没有使用g编译的程序

GDB（GNU调试器）是一个强大的工具，不仅可以用于调试编译时包含调试信息的程序，还可以用于调试正在运行的进程，甚至是没有使用 -g 选项编译的程序。以下是如何使用GDB调试正在运行的进程和没有使用 -g 编译的进程的详细指南。

1. 调试正在运行的进程

调试正在运行的进程需要GDB附加到该进程上。以下是具体步骤：

1.1 查找进程ID (PID)

首先，找出你要调试的进程的PID。可以使用 ps 命令来列出进程及其PID：

ps aux | grep <process_name>

或者使用 pgrep 命令直接获取PID：

pgrep <process_name>

1.2 使用GDB附加到进程

使用GDB附加到正在运行的进程：

gdb -p <pid>

例如：

gdb -p 1234

在GDB中，你可以使用以下命令来调试进程：

• 查看进程的堆栈跟踪：

  (gdb) bt
  

• 查看当前执行位置：

  (gdb) info proc mappings
  

  或者：

  (gdb) info proc
  

• 设置断点：

  如果你知道某个函数名或文件名和行号，可以设置断点：

  (gdb) break <function_name>
  

  或：

  (gdb) break <source_file>:<line_number>
  

• 继续执行：

  如果进程在断点处暂停，你可以继续执行：

  (gdb) continue
  

• 打印变量的值：

  (gdb) print <variable_name>
  

• 调试信息：

  查看详细的调试信息，例如线程和堆栈状态：

  (gdb) info threads
  (gdb) thread <thread_id>
  

1.3 断开调试并恢复进程

调试完成后，你可以使用以下命令断开GDB与进程的连接：

(gdb) detach

然后退出GDB：

(gdb) quit

2. 调试没有使用 -g 编译的程序

如果程序没有使用 -g 选项进行编译，它将没有调试信息，这使得调试变得更加困难。但GDB仍然可以提供一些有用的信息：

2.1 加载可执行文件和coredump

如果你有程序的coredump文件，可以使用GDB加载它：

gdb <executable> <corefile>

例如：

gdb ./my_program core.1234

即使没有调试信息，GDB仍能显示崩溃位置的汇编代码和符号信息。

2.2 查看符号表

如果程序没有调试信息，你可以查看符号表（函数名和变量名），但会比较有限：

(gdb) info functions
(gdb) info variables

这些命令可以显示程序中已知的函数和变量，但没有详细信息。

2.3 使用反汇编

如果没有调试信息，你可以使用反汇编命令来查看崩溃时的汇编代码：

(gdb) disassemble /m

这将显示包含源代码的汇编代码。如果没有源代码，它将只显示汇编代码：

(gdb) disassemble

2.4 调试技巧

• 设置断点：

  如果你知道函数的名称或地址，可以设置断点：

  (gdb) break *0x<address>
  

• 查看寄存器值：

  查看寄存器的值，以便了解崩溃时的状态：

  (gdb) info registers
  

总结

• 调试正在运行的进程：使用 gdb -p <pid> 附加到进程，设置断点、查看堆栈跟踪、打印变量等。
• 调试没有 -g 编译的程序：虽然没有详细的调试信息，你仍然可以加载coredump文件，使用反汇编和查看符号表来进行有限的调试。

这些步骤将帮助你在没有完全调试信息的情况下进行调试，并尽可能地获取有用的信息。

补充

即使程序在编译时没有使用 -g 选项，也可以生成 coredump 文件，并且你仍然可以在 GDB 中对没有调试信息的程序设置断点。下面是详细的操作说明：

1. 生成 coredump 文件

即使程序没有使用 -g 编译选项，coredump 文件仍然会被生成。你可以按照以下步骤生成 coredump 文件：

1.1 确保系统配置正确

确保系统配置允许生成 coredump 文件：

• 设置 coredump 文件大小限制：

  ulimit -c unlimited
  

• 配置 coredump 文件的生成路径（可选）：

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

1.2 运行程序以生成 coredump 文件

执行程序以触发崩溃并生成 coredump 文件。例如：

./my_program

崩溃后，coredump 文件将被保存到你指定的路径（如 /tmp）。

2. 使用 GDB 调试没有调试信息的程序

即使程序没有使用 -g 编译，GDB 仍然可以加载和分析 coredump 文件。以下是如何操作：

2.1 加载 coredump 文件

使用 GDB 加载 coredump 文件和程序的可执行文件：

gdb <executable> <corefile>

例如：

gdb ./my_program core.1234

2.2 查看崩溃时的堆栈信息

即使没有调试信息，GDB 仍然能够显示崩溃时的堆栈跟踪和函数调用信息：

(gdb) bt

2.3 设置断点

虽然没有源代码的调试信息，但你仍然可以在函数地址上设置断点。你需要知道函数的名称或地址：

• 设置函数断点：

  (gdb) break <function_name>
  

  如果没有调试信息，可能无法直接使用函数名，但你可以使用地址：

• 设置地址断点：

  (gdb) break *0x<address>
  

  你可以使用 info proc mappings 查看可执行文件的内存映射来获取函数地址。

2.4 查看汇编代码

如果没有调试信息，GDB 仍然可以显示崩溃时的汇编代码：

(gdb) disassemble /m

这将显示包含源代码的汇编代码。如果源代码不可用，只能查看纯汇编代码：

(gdb) disassemble

2.5 查看寄存器值

查看寄存器的值，以帮助理解崩溃时的程序状态：

(gdb) info registers

总结

即使程序没有使用 -g 选项编译，GDB 仍然可以生成和分析 coredump 文件，并允许你在程序中设置断点。虽然调试信息有限，但你仍然可以通过设置地址断点、查看汇编代码和寄存器来进行调试。这些技术可以帮助你在没有详细调试信息的情况下定位和解决问题。