Linux 上的 C 和 C++ 编程软件和调试工具

首页» Python » Linux 上的 C 和 C++ 编程软件和调试工具

如果你之前一直使用 Windows + Visual Studio，突然转到 Linux 系统上处理一个庞大的 C 或 C++ 代码库，这种转变可能会让你感觉非常不适应。在 VS Code 之类的编辑器后面，用 GDB 单步调试几十万行代码，每一步都要等待 30-60 秒，你可能会怀疑自己是不是哪里做错了，或者 Linux 开发本身就慢。好消息是，现代 Linux 工具链和调试器功能非常强大；你只需要知道如何配置它们，以及哪些工具适合大型 C/C++ 项目。

本指南将带您了解 Linux 上的 C/C++ 编译器、IDE 和调试工具（参见《从零开始精通 Linux》），从 GCC、Clang/LLVM 和 IBM Open XL C/C++ 到 GDB、Eclipse、SystemTap、strace、ltrace 以及高级核心转储工作流程。在此过程中，我们还将介绍经典的学习配置（例如 Geany + GCC），并提供一些实用技巧，以加快调试速度，让您在 Linux 上使用 C 和 C++ 进行开发时，获得与在 Windows 上类似的舒适体验。

Linux 平台上的 C 和 C++ 编译器：GCC、Clang/LLVM 和 IBM Open XL

在 Linux 系统上，C 和 C++ 的参考工具链仍然是 GCC（GNU 编译器集合），其 C++ 前端是 g++。 大多数发行版默认都包含 GCC，几乎所有教程、构建系统和 CI 流水线都假定它已安装。您通常使用类似这样的命令进行编译： gcc 对于 C 和 g++ 例如，对于 C++ 来说。 g++ -g -O2 main.cpp -o app 构建可调试、优化的二进制文件。

Clang 和 LLVM 生态系统已发展成为 Linux 上 GCC 的强大替代方案，提供快速编译、出色的诊断功能和丰富的工具集（静态分析、代码格式化、清理器等等）。Clang 是基于 LLVM 构建的 C/C++ 前端，LLVM 是一个模块化的开源编译器基础设施，支持多种架构和语言，并由庞大的社区积极维护。

IBM Open XL C/C++ for Linux on Power 是一款商业工具链，它将 Clang/LLVM 与 IBM 长期积累的编译器优化经验紧密集成。该工具链专为 IBM Power 系统设计，充分利用了现代 C/C++ 语言特性（包括 C++17）、标准的 LLVM 优化以及与 GCC 的兼容性，从而在 Power 硬件上提供高性能二进制文件。这意味着您不仅可以享受到 LLVM 生态系统的优势，还能获得 IBM 开发的平台优化功能。

对于传统环境，IBM 仍然提供较旧的 Linux 版 XL C/C++ 编译器，因此具有现有构建链或认证限制的组织可以继续使用这些编译器，同时逐步采用 Open XL C/C++ 来处理更新的工作负载。

经典学习配置：GCC 和轻量级 IDE

如果你刚开始在 Linux 系统上使用 C 或 C++ 编程，一个非常常见且高效的方案是 GCC 编译器搭配轻量级 IDE，例如 Geany。Geany是跨平台的（支持 Linux 和 Windows），速度快，并且集成了项目管理、构建命令和简易调试等基本功能，而不会像功能齐全的大型 IDE 那样占用大量资源。

许多面向 Linux 的长篇 C/C++ 课程都推荐使用 GCC 作为编译器，Geany 作为开发环境。通过这类教程，你通常可以从零开始学习这门语言：GNU 编译器是什么以及如何调用它，如何构建程序结构，如何使用条件语句、函数、数组、字符串、指针、结构体、联合体、文件 I/O，最终还会学习 C++ 中的面向对象概念，例如继承、运算符重载和多态。

虽然 IDE 的选择各不相同，但底层工具链的建议往往是一致的：尽可能在各个平台上使用 GCC（或 g++）。在 Linux 系统上，这是默认设置；在 Windows 和 macOS 系统上，您可以通过 MinGW、MSYS2、WSL、Homebrew 或类似工具安装 GCC，从而在不同系统间保持统一的工作流程，并简化脚本和 Makefile 的共享。

即使 IDE 对构建步骤进行了抽象，理解它本质上仍然是调用。 gcc or g++ 幕后工作对于调试复杂的构建或运行时问题至关重要。 像这样的选项 -g 用于调试信息、优化级别等 -O0, -O2 or -O3以及用于调整警告或标准合规性的标志（-Wall, -std=c++17等等）在诊断细微错误时都至关重要。

大型 C++ 代码库的调试：从 VS Code 到原生 GDB

从 Windows 上的 Visual Studio 迁移到 Linux 的开发者通常会先使用 Visual Studio Code 以及基于 GDB 的扩展，很快就会发现，在调试大型后端时，单步调试会变得异常缓慢。调试包含数十万行代码和众多后端组件的大型文档处理或交付系统时，每一步延迟 30 到 60 秒的情况并不少见。

这种运行缓慢的情况通常并非 GDB 本身的限制，而是 VS Code 与底层调试器之间的集成层或配置问题。调试扩展程序的问题、断点同步方式、符号信息加载方式以及机器接口 (MI) 命令转换方式等都可能导致复杂的实际应用程序运行速度大幅下降。

VS Code C/C++ 扩展程序在 Linux 系统上使用 GDB 进行单步调试时存在一些长期存在的性能问题。对于某些团队而言，这意味着 VS Code 作为编辑器非常出色，但作为调试大型 C++ 服务的前端，它未必是速度最快的选择；其他替代方案包括Google Antigravity IDE和原生 IDE。当性能至关重要时，许多工程师会选择直接使用 GDB，或者切换到与本地工具链深度集成的原生 IDE。

因此，如果您发现 Linux 系统下 VS Code 调试会话中每一步都要花费半分钟，不要想当然地认为 Linux 调试本身就这么慢。在放弃之前，不妨尝试在终端中直接用 GDB 调试同一个二进制文件，并比较结果。通常情况下，在 GDB 中单步调试的速度会快得多，这表明瓶颈在于配置或扩展程序，而不是操作系统或编译器本身的问题。

在基于 Linux 的大型 C++ 开发环境中，为了方便调试，常用的替代方案包括使用 CDT（C/C++ 开发工具）的 Eclipse、CLion、Qt Creator、KDevelop 以及其他与 GDB 和本地系统集成更紧密的原生 IDE。这些环境可以提供源代码导航、监视窗口和丰富的断点功能，同时底层仍然使用 GDB，而无需语言无关的调试层带来的额外开销。

Linux 上的调试信息：ELF、DWARF、debuginfo 和 debugsource

在 Linux 系统中，编译后的程序和共享库通常存储在 ELF（可执行和可链接格式）文件中，而它们相关的调试信息则以 DWARF 格式编码。DWARF包含调试器将机器代码映射回源文件所需的元数据，包括行号、函数、类型和变量。

您可以使用诸如以下工具来检查 ELF 二进制文件中的 DWARF 部分： readelf -w file它会转储原始调试记录。 虽然通常不会手动读取 DWARF，但这可以确认是否存在调试信息，并且对于诊断 GDB 或其他工具中的“未加载符号”类型的问题非常有价值。

一种名为 STABS 的旧式调试格式仍然存在，但已被视为过时，并且在 Red Hat Enterprise Linux 等现代 Linux 发行版中不推荐使用。GCC和 GDB 尽力支持 STABS，但生态系统中的关键工具（例如 Valgrind 或 elfutils）可能无法正确兼容，因此强烈建议使用 DWARF。

由于调试数据通常很大，大多数发行版会将其从主二进制文件中分离出来，分别打包成单独的 debuginfo 和 debugsource 包。从默认软件仓库安装的可执行文件通常会移除调试符号，以节省磁盘空间并减少内存占用；而相应的 debuginfo 包包含 DWARF 数据，debugsource 包则可选地包含匹配的源代码。

在 RHEL 和类似系统中，您可以使用以下命令在编译时显式请求调试信息。 -g 使用 GCC 构建自己的项目时。 对于通过软件包安装的系统库和第三方库，您可以获取相关信息。 debuginfo 和 debugsource 来自专门的调试存储库的软件包，通常在调试会话期间，当 GDB 发现缺少符号时，会直接提示这些软件包。

安装和定位系统二进制文件的调试信息

调试依赖于系统库的 C 或 C++ 程序时，为这些库安装 debuginfo 工具可以显著提升回溯信息和变量检查的质量。如果没有 debuginfo，你只能看到共享库中的原始地址或经过修饰的函数名；而有了 debuginfo，你就能获得精确到行的堆栈跟踪和符号化的变量名。

在类似 RHEL 的发行版上，GNU 调试器 (GDB) 可以自动检测已加载对象何时缺少调试信息，并提供具体的命令来安装必要的调试信息。 debuginfo 封装通过 dnf. 您只需运行推荐的程序即可。 dnf debuginfo-install ... 命令执行后，在提示时确认，系统将获取并安装会话所需的符号包。

如果无法自动获取提示，您可以使用诸如 之类的工具找到二进制文件或库文件，从而手动识别所需的调试信息。 locate 然后查询 RPM 数据库。 此 locate 命令来自 mlocate 您可能需要安装和初始化该软件包，一旦您获得了路径，就可以询问哪个软件包拥有它，然后安装相应的 debuginfo 变体。

有些情况下，无法确定安装了给定二进制文件的软件包，例如，当文件是手动复制的，或者在没有打包的情况下就地构建时。 在这种情况下，您可能需要使用自定义符号文件，或者如果可能的话，自行重新构建二进制文件。 -g 启用此功能后，GDB 将拥有完整的调试数据。

请记住，为系统中的每个库安装调试信息很少是必要的，而且会造成资源浪费。应该专注于与问题最相关的模块：应用程序二进制文件以及导致崩溃或异常行为的特定库，而不是为整个操作系统安装调试包。

在 Linux 上使用 GDB 进行交互式调试

GDB 是 Linux 系统上用于调试原生 C 和 C++ 应用程序的核心工具，它既提供命令行界面，也通过集成提供图形化前端，例如 Eclipse CDT。在 Red Hat Enterprise Linux 系统中，标准发行版包含功能齐全的 GDB 以及可选的图形用户界面。

要从头开始调试程序，通常需要调用 gdb ./program根据需要配置断点，然后使用 GDB 启动执行。 run 命令。 或者，您可以将其附加到已在运行的程序上。 gdb -p <pid> 或者通过启动 GDB 并使用 attach 命令以及进程 ID。

如果在附加过程中 GDB 无法推断给定 PID 的目标可执行文件，您可以通过以下方式显式地告诉它要使用哪个二进制文件： file 然后执行命令并进行调试。 当您处理自定义启动器、包装脚本或多二进制设置时，实际可执行路径并不明显，这时此功能尤其有用。

一旦连接或启动，您就可以使用诸如以下的命令来控制程序流程： n （下一个）， s （步）， until, finish 和简单地 c （继续），同时退出调试器 q 完成后。 这些命令各自具有特定的语义，决定了它是进入函数体、运行到指定行还是恢复执行直到下一个断点或终止。

为了理解系统状态，GDB 提供了丰富的自省命令来检查变量、调用栈、寄存器等等，并且还提供上下文帮助。 help info 以及类似命令。 您可以使用以下命令显示当前源代码行 list，打印变量 print探索堆栈帧 backtrace 并使用以下方式导航框架 frame, up 和 down.

GDB 中的断点、监视点和条件

在实际调试中，你几乎从不会盲目地从……迈出一步 main()相反，你可以策略性地设置断点，以便在行为变得有趣时准确地停止程序。 标准命令 break 允许您按文件和行号或函数名设置断点，GDB 将在下次命中时暂停执行。

例如，您可以使用如下语法在特定的源代码行上设置断点： break file.cpp:123或者在函数开始时中断 break my_function. 当程序到达断点位置时，GDB 会暂停程序，让您检查局部变量、检查调用堆栈，并决定是单步执行、单步跳过还是继续执行。

当错误仅在多次迭代后或在特定输入值下出现时，条件断点就显得尤为重要。您可以将用 C 或 C++ 编写的布尔条件与断点关联起来，这样 GDB 仅在条件为真时才会停止，从而显著减少不必要的停止，并大大提高调试循环或复杂状态机的效率。

为了监控数据变化而不是代码流，GDB 提供了监视点，当从表达式（通常是变量）读取或写入表达式时，监视点会触发。 使用诸如这样的命令 watch, rwatch （读）或 awatch （读/写），您可以精确地在某个字段被修改或访问时停止执行，这对于追踪意外的状态变化特别有帮助。

您可以通过诸如以下的命令管理所有断点和监视点： info breakpoints or info br您可以使用以下方式按编号或位置删除： delete 有适当的论据。 这样可以轻松保持一组清晰的活动断点，并防止在跨多个模块或会话进行调试时出现混淆。

调试多线程和派生进程

调试大量使用线程或分支的 C 和 C++ 程序需要对 GDB 如何跟踪执行上下文有一些额外的了解。 默认情况下，GDB 会指定一个当前线程，大多数命令都在该线程上运行，除非您显式地使用 `using` 语句进行切换。 thread 以及线程标识符。

当你的程序分支时，设置 set detach-on-fork 确定 GDB 是跟随子进程还是父进程，以及如何处理未被跟随的进程。 您可以配置 GDB 来同时控制两者，或者根据父节点、子节点或两者都与您的分析相关，自动从其中一方分离。

新版本的 GDB 改进了线程编号方式，引入了每个底层线程的 ID 以及一个独特的全局线程 ID 以实现兼容性。 便利变量 $_thread 以及 Python API 的 InferiorThread.num 现在按下级编号，而全局标识符可通过以下方式获取： $_gthread 和 InferiorThread.global_num确保基于全局 ID 的旧工具继续正常工作。

多线程调试中的信号处理也得到了改进，确保信号始终传递到正确的线程。如果在信号导致程序停止后切换线程，然后尝试继续执行，GDB 会请求确认，从而防止意外的错误传递，使信号相关的调试更加可靠。

这意味着，在分析死锁、竞争条件或奇怪的信号触发崩溃时，您可以依靠 GDB 的线程模型来精确跟踪正确的执行路径。结合断点、监视点和捕获点，即使在高度并发的 C++ 服务中，也能实现强大的多线程调试。

跟踪系统和库调用：strace、ltrace 和 SystemTap

有时，要了解 C 或 C++ 程序为何运行异常，最快的方法并非逐行执行，而是观察它如何与操作系统及其共享库交互。Linux提供了几个强大的工具来实现这一点：strace、ltrace、SystemTap，甚至 GDB 本身也通过专门的捕获点来实现。

此 strace 实用程序跟踪系统调用——与内核的交互，例如 open, read, write, mmap, execve 等等——以及它们的参数和返回值。 你可以通过以下方式运行你的程序 strace 或者通过 PID 附加到正在运行的进程，还可以选择使用表达式筛选要显示的系统调用，例如 -e trace=call 并控制是否跟随分叉或串联的子项 -f.

因为实际应用程序会发出大量的系统调用，所以需要结合使用。 strace 使用 shell 工具，例如 tee 实时查看输出结果并将其存储起来进行分析是很常见的做法。 这有助于您识别缺失的文件、权限问题、意外的网络行为或其他操作系统级别的问题，这些问题可能从代码本身并不明显。

与 strace 互补， ltrace 重点关注用户空间中对共享库函数的调用，显示动态对象导出函数的调用和返回值。 在 RHEL 8 上，ltrace 存在一个已知的限制，即无法跟踪某些系统可执行文件，但对于用户构建的二进制文件，它工作正常，这使其成为了解程序如何使用库 API 的宝贵工具。

SystemTap 是一个更高级的跟踪框架，它允许使用自己的脚本语言为内核空间和用户空间事件编写自定义事件处理程序。 它比 strace 或 ltrace 更复杂，但可扩展性更好，并支持复杂的过滤和聚合。为了方便起见，这里提供了一个名为 的示例脚本 strace.stp 它与 SystemTap 集成，利用 SystemTap 的基础架构来模拟类似 strace 的行为。

GDB 本身可以通过使用系统调用和信号的捕获点参与跟踪，例如通过类似这样的命令。 catch syscall 和 catch signal. 这些功能可以让调试器在程序执行某些系统调用或接收特定信号时停止执行，这在交互式调试期间需要细粒度控制时非常有用。

使用 GDB 生成核心转储文件并进行事后调试

当 C 或 C++ 应用程序崩溃或挂起且难以通过交互方式重现时，核心转储文件可以提供程序在关键时刻的内存和状态快照。核心转储文件是一个 ELF 文件，其中包含进程终止时部分内存（堆栈、堆、映射）的内容，您可以稍后使用 GDB 对其进行分析，就像您在崩溃发生时处于连接状态一样。

要有效利用核心转储文件，必须确保它们实际生成，并且不受资源限制或配置的阻止。 Shell 的限制，例如 ulimit -c 可以阻止创建核心文件；将限制设置为 unlimited 虽然取消了大小限制，但您应该考虑在生产系统中对磁盘空间的影响。

在现代RHEL系统中， systemd-coredump 它以透明的方式管理核心转储文件，并将其存储在类似日志的集中位置，而不是将其留在系统中。 core 文件散落在各个目录中。 此 coredumpctl 该工具允许您列出已记录的崩溃，检查其元数据，并将实际核心文件导出到选定的路径以进行更深入的分析。

在创建系统化的崩溃捕获工作流程时，通常会安装 sos 包装和使用 sosreport 生成包含系统配置和日志的 tar 包。 结合导出的核心文件和应用程序二进制文件，您可以获得在单独的机器上分析崩溃或将其移交给其他团队或供应商所需的一切。

你甚至可以通过向无响应进程发送中止信号或使用类似工具来故意触发核心转储。 gcore它会在进程仍在运行时转储进程内存。 在一个 gcore 转储时，进程会短暂暂停，然后恢复正常执行，从而可以在不完全终止服务的情况下对问题状态进行离线分析。

找到用于核心分析的正确可执行文件和符号

为了有效地分析核心转储文件，GDB 需要核心转储文件以及生成该文件的确切可执行文件（以及任何相关的共享库）。这一点至关重要，因为由不同版本构建的不匹配二进制文件会导致误导性的回溯信息和错误的变量布局。

像工具一样 coredumpctl info 显示每个捕获到的核心的详细元数据，包括主可执行文件的路径和唯一标识二进制文件的构建 ID。 构建 ID 可能看起来像一个很长的十六进制哈希值，您可以将其与本地二进制副本的构建 ID 进行比较，以确保它们在启动 GDB 之前是相同的。

如果可执行文件及其库来自 RPM 包，则可以使用 sosreport 以及软件包数据库，用于获取所需的确切版本。 在某些情况下，您甚至可以在专用调试机器上重新安装匹配的软件包，然后使用 GDB 的 set sysroot 配置使其指向镜像库布局，以便进行远程调试。

获取到正确的对象后，可以使用类似这样的命令启动 GDB 会话： gdb /path/to/exe /path/to/core 然后让 GDB 加载核心。 如果任何模块缺少调试信息，GDB 将显示消息，提示您应该安装哪些软件包或符号文件才能获得完整的符号可见性。

如果你的应用程序调试符号不是通过包提供的，而是放在单独的文件中，你可以使用以下方式显式加载它们： symbol-file GDB 内部命令。 您不必为核心中的每个共享库都获取调试信息；通常，专注于您自己的应用程序和可疑库就足以重建相关的堆栈和状态。

分析核心转储文件时，请记住，由于没有运行中的进程，控制程序执行的命令（例如单步执行或继续执行）不再有效。相反，您需要依靠检查命令——检查堆栈帧、局部变量和全局变量、内存区域和线程——来推断崩溃原因或程序卡住的位置。

现代 RHEL 上的高级内存转储场景和 GDB 更改

某些高安全性或高性能应用程序会使用诸如以下标志将部分内存标记为不可转储： VM_DONTDUMP这样就阻止了该内存被写入核心文件。 这样可以保护敏感数据（例如加密密钥或财务记录），并减少转储大小，但会使完整的离线分析变得更加困难。

如果您非常需要捕获所有内容（包括通常从转储中排除的区域），您可以配置 GDB 忽略非转储标志并强制执行全面的内存转储。 GDB 提供了一些选项来覆盖这些选项。 VM_DONTDUMP 并将整个进程内存转储到核心转储文件中，以便进行取证或深度调试。

在工具方面，RHEL 8 自带的 GDB 版本相比 RHEL 7 引入了一些重大变更和行为改变，尤其是在用户过去需要解析其终端输出的领域。Red Hat 建议用户使用 GDB 的 Python API 或机器接口 (MI) 协议编写脚本，而不是抓取文本输出，这两种方式都专为程序化使用而设计。

值得注意的变化包括：GDBserver 通过 shell 启动下级程序以允许参数扩展；移除 GCJ（Java）支持；更新维护符号转储命令的语法；以及调整 sysroot 处理以更好地支持远程调试。 某些命令和模式，例如 HP-UX XDB 兼容性和 remotebaud已被弃用或被更通用的等效词取代，例如 set serial baud.

此外，GDB 还引入了诸如以下限制： max-value-size 为了防止在打印非常大的值时出现无限制的内存分配，我们改变了控制命令历史记录大小的方式。 GDBHISTSIZE 而不是 HISTSIZE并增加了完成候选人数量的限制 set max-completions. 这些安全措施有助于避免在调试病态或损坏的程序时出现程序卡死或内存过度消耗的情况。

对于 Linux 上的 C 和 C++ 开发人员而言，GDB 的最终效果是提供了一个更强大、更易于脚本化的调试器，它能够处理庞大的代码库和各种奇特的故障场景，前提是您了解更新后的命令和配置选项。结合 GCC 和 Clang/LLVM 等现代编译器基础架构（以及 IBM Open XL C/C++ on Power 等产品），GDB 构成了一个强大的工具链，用于在 Linux 上开发和调试复杂的本地软件。

选择合适的编译器和 IDE，启用 DWARF 调试信息并安装调试信息包，以及利用 GDB、strace、ltrace、SystemTap 和核心转储工作流程，就能获得一个快速、透明且适用于大型后端的 Linux C/C++ 环境，即使您最初对 Linux 的印象来自于缓慢的 VS Code 调试会话。通过正确的配置和对可用工具的了解，在 Linux 上进行调试不仅可以媲美 Windows 上的 Visual Studio，而且在许多情况下，它还能让您更精细地控制和更深入地了解 C 和 C++ 应用程序的实际运行情况。