在 RHEL 8 中开发 C 和 C++ 应用程序

1. 进到包含您代码的目录。

2. 编译带有 foo 库的头的程序源文件：

   $ gcc ... -Iheader_path -c ...

   使用包含 foo 库的头文件的目录的路径替换 header_path。

3. 将程序与 foo 库链接：

   $ gcc ... -Llibrary_path -lfoo ...

   使用包含文件 libfoo.a 的目录的路径替换 library_path。

4. 要稍后运行该程序，只需：

   $ ./program

1. 设置 LD_LIBRARY_PATH 环境变量：

   $ export LD_LIBRARY_PATH=library_path:$LD_LIBRARY_PATH

2. 运行程序：

   $ ./program

流程

1. 进到有库源文件的目录。

2. 使用位置独立代码选项 -fPIC 将每个源文件编译成目标文件：

   $ gcc ... -c -fPIC some_file.c ...

   目标文件具有与原始源代码文件相同的文件名，但它们的扩展名是 .o。

3. 链接目标文件的共享库：

   $ gcc -shared -o libfoo.so.x.y -Wl,-soname,libfoo.so.x some_file.o ...

   使用的主版本号是 X ，次版本号是 Y。

4. 将 libfoo.so.x.y 文件复制到合适的位置，其中系统的动态链接器可以找到它。在 Red Hat Enterprise Linux 中，库的目录是 /usr/lib64 ：

   # cp libfoo.so.x.y /usr/lib64

   请注意，您需要 root 权限才能操作此目录中的文件。

5. 为 soname 机制创建符号链接结构：

   # ln -s libfoo.so.x.y libfoo.so.x

6. 创建第二个符号链接：

   # ln -s libfoo.so.x libfoo.so

流程

1. 使用 GCC 创建中间目标文件。

   $ gcc -c source_file.c ...

   如果需要，可附加更多源文件。生成的目标文件共享文件名，但使用 .o 文件扩展名。

2. 使用 binutils 软件包中的 ar 工具将目标文件转换为静态库（存档）。

   $ ar rcs libfoo.a source_file.o ...

   文件 libfoo.a 已创建。

3. 使用 nm 命令检查生成的归档：

   $ nm libfoo.a

4. 将静态库文件复制到合适的目录。

5. 与库链接时，GCC 将自动从 .a 文件扩展名中识别出库是一个用于静态链接的存档。

   $ gcc ... -lfoo ...

流程

1. 创建 hellomake 目录：

   $ mkdir hellomake

2. 进入 hellomake 目录：

   $ cd hellomake

3. 创建包含以下内容的文件 hello.c ：

   #include <stdio.h>
   
   int main(int argc, char *argv[]) {
     printf("Hello, World!\n");
     return 0;
   }

4. 创建包含以下内容的文件 Makefile ：

   CC=gcc
   CFLAGS=-c -Wall
   SOURCE=hello.c
   OBJ=$(SOURCE:.c=.o)
   EXE=hello
   
   all: $(SOURCE) $(EXE)
   
   $(EXE): $(OBJ)
           $(CC) $(OBJ) -o $@
   
   %.o: %.c
           $(CC) $(CFLAGS) $< -o $@
   
   clean:
           rm -rf $(OBJ) $(EXE)

   重要

   Makefile recipe 行必须以制表符字符开头！从文档中复制上面的文本时，剪切和粘贴过程可能会粘贴空格而不是制表符。如果发生这种情况，请手动纠正问题。

5. 运行 make ：

   $ make

   $ gcc -c -Wall hello.c -o hello.o
   $ gcc hello.o -o hello

   这将创建一个可执行文件 hello。

6. 运行可执行文件 hello ：

   $ ./hello

   Hello, World!

7. 运行 Makefile 目标 clean 以删除创建的文件：

   $ make clean

   # rm -rf hello.o hello

流程

1. 启动连接到要调试的应用程序或库的 GDB。GDB 自动识别缺少的调试信息，并建议要运行的命令。

   $ gdb -q /bin/ls

   Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
   (no debugging symbols found)...done.
   Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
   (gdb)

2. 退出 GDB：输入 q 并使用 Enter 进行确认。

   (gdb) q

3. 运行 GDB 建议的命令来安装所需的 debuginfo 软件包：

   # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

   dnf 软件包管理工具提供更改摘要、要求确认，并在确认后，下载并安装所有必需的文件。

4. 如果 GDB 没有推荐 debuginfo 软件包，请按照 第 3.1.5 节 “手动为应用程序或库获取 debuginfo 软件包” 中描述的流程操作。

流程

1. 查找应用程序或库的可执行文件。

   1. 使用 which 查找应用程序文件。

      $ which less

      /usr/bin/less

   2. 使用 locate 命令查找库文件。

      $ locate libz | grep so

      /usr/lib64/libz.so.1
      /usr/lib64/libz.so.1.2.11

      如果调试的最初原因包含错误消息，请选择库的文件名中与错误消息中提及的具有相同的额外数字的结果。若有疑问，请使用文件名不包含其他数字的结果来尝试遵循该流程的其余部分。

      注意

      locate 命令由 mlocate 软件包提供。要安装并启用它：

      1. 安装 mlocate 软件包：

         # yum install mlocate

      2. 更新数据库：

         # updatedb

2. 搜索提供该文件的软件包的名称和版本：

   $ rpm -qf /usr/lib64/libz.so.1.2.7

   zlib-1.2.11-10.el8.x86_64

   输出以 name:epoch-version.release.architecture 格式提供已安装软件包的详细信息。

   重要

   如果此步骤没有生成任何结果，则无法确定哪一个软件包提供了二进制文件。有几个可能的情况：

   • 文件是从 current 配置中包管理工具不知道的包安装的。
   • 文件从本地下载和手动安装的包中安装的。在这种情况下，自动确定合适的 debuginfo 软件包是不可能的。
   • 您的软件包管理工具配置错误。
   • 文件不是从任何软件包安装的。在这种情况下，没有对应的 debuginfo 软件包存在。

   因为后续步骤依赖于此，所以您必须解决这种情况或中止这个过程。描述确切的故障排除步骤不在本流程范围内。

3. 使用 debuginfo-install 工具安装 debuginfo 软件包。在命令中，使用软件包名称以及您在上一步中确定的其他详情：

   # debuginfo-install zlib-1.2.11-10.el8.x86_64

1. 使用 ps 命令找到进程 ID(pid)：

   $ ps -C program -o pid h

   使用程序的文件名或路径替换 program。

2. 将 GDB 附加到此进程：

   $ gdb -p pid

   使用 ps 输出中的实际进程 ID 号替换 pid 。

1. 使用 shell GDB 命令运行 ps 命令，并找到程序的进程 ID(pid)：

   (gdb) shell ps -C program -o pid h

   使用程序的文件名或路径替换 program。

2. 使用 attach 命令将 GDB 附加到程序：

   (gdb) attach pid

   使用 ps 输出中的实际进程 ID 号替换 pid。

流程

1. 确定要监控的系统调用。

2. Start strace 并将其附加到 程序。

   • 如果您要监控的程序没有运行，请启动 追踪 并指定 程序 ：

     $ strace -fvttTyy -s 256 -e trace=call program

   • 如果程序已在运行，请查找其进程 ID(pid) 并附加至 该程序：

     1. 查找进程 ID：

        $ ps -C program

        (...)

     2. 将 strace 附加到进程：

        $ strace -fvttTyy -s 256 -e trace=call -ppid

   • 将 call 替换为要显示的系统调用。您可以多次使用 -e trace=call 选项。如果遗漏，strace 将显示所有系统调用类型。如需更多信息，请参阅 strace(1) 手册页。
   • 如果您不想跟踪任何分叉的进程或线程，请退出 -f 选项。

3. strace 工具显示应用程序发出的系统调用及其详细信息。

   在大多数情况下，如果未设置系统调用过滤器，应用及其库都会立即发出大量调用和 strace 输出。

4. 当程序退出时，The strace 工具会退出。

   要在 traced 程序退出前终止监控，请按 Ctrl+C。

   • If strace 启动程序，程序与 strace 一起终止。
   • 如果您 将 trace 附加到 已在运行的程序，程序会一起终止 。

5. 分析应用执行的系统调用列表。

   • 当调用返回错误时，日志中会出现与资源访问或可用性相关的问题。
   • 传递给系统调用和调用序列模式的值可让您了解应用程序的原因。
   • 如果应用崩溃，重要信息或许位于日志的末尾。
   • 输出中包含大量不必要的信息。但是，您可以为感兴趣的系统调用构建更精确的过滤器，并重复该过程。

流程

1. 识别感兴趣的库和功能（如果可能）。

2. 启动 ltrace 并将其附加到 程序。

   • 如果您要监控的程序没有运行，请启动 ltrace 并指定 程序 ：

     $ ltrace -f -l library -e function program

   • 如果程序已在运行，请查找其进程 ID(pid)并附加 ltrace 到其中：

3. 查找进程 ID：

   $ ps -C program

   (...)

4. 将 ltrace 附加到进程：

   $ ltrace -f -l library -e function program -ppid

   • 使用 -e、-f 和 -l 选项过滤输出：

     • 提供要显示为 function 的函数名称。e 函数 选项可多次使用。如果遗漏，ltrace 会显示对所有功能的调用。
     • 您可以使用 -l 库 选项指定整个库，而不是指定函数。这个选项的行为与 -e 函数 选项类似。
     • 如果您不想跟踪任何分叉的进程或线程，请退出 -f 选项。

     如需更多信息，请参阅 ltrace(1)_ 手册页。

5. ltrace 显示应用发出的库调用。

   在大多数情况下，如果未设置过滤器，应用会立即发出大量调用和 ltrace 输出。

6. 当程序 退出时，ltrace 会退出。

   要在 traced 程序退出前终止监控，请按 enter ctrl+C。

   • 如果 ltrace 启动了程序，程序会一起使用 ltrace 终止。
   • 如果您将 ltrace 附加到已在运行的程序，程序会一起终止 ltrace。

7. 分析应用执行的库调用列表。

   • 如果应用崩溃，重要信息或许位于日志的末尾。
   • 输出中包含大量不必要的信息。但是，您可以构建一个更精确的过滤器并重复该过程。

流程

1. 查找您要监控的进程的进程 ID(pid)：

   $ ps -aux

2. 使用 the strace.stp 脚本运行 SystemTap：

   # stap /usr/share/systemtap/examples/process/strace.stp -x pid

   pid 的值是进程 ID。

   脚本编译到内核模块，然后载入该模块。这在输入命令和获取输出之间引入了一些延迟。

3. 当进程执行系统调用时，调用名称及其参数将打印到终端。
4. 当进程终止或按 Ctrl+C 时，脚本将退出。

流程

1. 设置捕获点：

   (gdb) catch syscall syscall-name

   捕获系统调用的命令 设置一种特殊的断点类型，在程序执行系统调用时停止执行。

   syscall-name 选项指定调用的名称。您可以为各种系统调用指定多个捕获点。退出 syscall-name 选项会导致 GDB 在任何系统调用时停止。

2. 开始执行 程序。

   • 如果程序还没有开始执行，请启动它：

     (gdb) r

   • 如果程序执行被停止，恢复它：

     (gdb) c

3. GDB 在程序执行任何指定系统调用后停止执行。

流程

1. 设置捕获点：

   (gdb) catch signal signal-type

   命令 捕获信号 会设置一种特殊的断点类型，它会在程序收到信号时暂停执行。signal-type 选项指定信号的类型。使用特殊值 'all' 来 捕获所有信号。

2. 让程序运行。

   • 如果程序还没有开始执行，请启动它：

     (gdb) r

   • 如果程序执行被停止，恢复它：

     (gdb) c

3. GDB 在程序收到任何指定信号后停止执行。

流程

1. 要启用内核转储，请确保 /etc/systemd/system.conf 文件包含以下行：

   DumpCore=yes
   DefaultLimitCORE=infinity

   您还可以添加注释，描述之前是否存在这些设置以及之前的值。如果需要，这将允许您稍后撤销这些更改。注释是以 # 字符开头的行。

   更改文件需要管理员级别访问权限。

2. 应用新配置：

   # systemctl daemon-reexec

3. 删除内核转储大小的限制：

   $ ulimit -c unlimited

   若要反转这一更改，可运行值为 0 的 命令，而不运行 无限 值。

4. 安装 sos 软件包，它提供用于收集系统信息的 sosreport 工具：

   # yum install sos

5. 当应用程序崩溃时，会生成核心转储并由 systemd-coredump 进行处理。

6. 创建 SOS 报告以提供有关系统的更多信息：

   # sosreport

   这将创建一个包含您系统信息的 .tar 存档，如配置文件的副本。

7. 找到内核转储：

   $ coredumpctl list executable-name

8. 导出内核转储：

   $ coredumpctl dump executable-name > /path/to/file-for-export

   如果应用多次崩溃，第一个命令的输出会列出更多捕获的核心转储。在这种情况下，使用其他信息为第二个命令构建更精确的查询。详情请查看 coredumpctl(1) 手册页。

9. 将核心转储和 SOS 报告传送到要进行调试的计算机。如果已知，也传输可执行文件。

   重要

   当可执行文件未知时，core 文件的后续分析会识别该文件。

10. 可选：传输后删除核心转储和 SOS 报告，以释放磁盘空间。

流程

1. 要识别发生崩溃的可执行文件，请使用核心转储文件运行 eu-unstrip 命令：

   $ eu-unstrip -n --core=./core.9814

   0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /usr/bin/sleep /usr/lib/debug/bin/sleep.debug [exe]
   0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1
   0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /usr/lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6
   0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /usr/lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2

   输出中包含一行中各个模块的详细信息，用空格分隔。此信息按以下顺序列出：

   1. 映射模块的内存地址
   2. 模块的 build-id 及其在内存中的位置
   3. 模块的可执行文件名称，如果未从文件加载为 - 时显示为 - when unknown 或 等 。
   4. 调试信息源（如果可用时显示为文件名），如 包含在 可执行文件本身中，或 （ 如果根本不存在）
   5. 主模块的共享库名称(soname)或 [exe]

   在本例中，重要的详细信息是文件名 /usr/bin/sleep 和 build-id 2818b2009547f780a5639c904cded443e564973e on the text [exe]。使用此信息，您可以识别分析核心转储所需的可执行文件。

2. 获取崩溃的可执行文件。

   • 如果可能，请从发生崩溃的系统中复制它。使用从 core 文件提取的文件名。

   • 您也可以在系统上使用相同的可执行文件。在 Red Hat Enterprise Linux 上构建的每个可执行文件都包含带有唯一 build-id 值的备注。确定相关的本地可用可执行文件的 build-id：

     $ eu-readelf -n executable_file

     使用此信息将远程系统上的可执行文件与您的本地副本匹配。内核转储中列出的本地文件和 build-id 的 build-id 必须匹配。

   • 最后，如果应用程序是从 RPM 软件包安装的，您可以从 软件包中获取可执行文件。使用 sosreport 输出来查找所需软件包的确切版本。
3. 获取由可执行文件使用的共享库。将与 相同的步骤用于 可执行文件。
4. 如果应用程序以软件包形式分发，请在 GDB 中加载可执行文件，以显示缺少 debuginfo 软件包的提示。如需了解更多详细信息，请参阅 第 3.1.4 节 “使用 GDB 获取应用程序或库的 debuginfo 软件包”。

5. 要详细检查核心文件，使用 GDB 加载可执行文件和核心转储文件：

   $ gdb -e executable_file -c core_file

   有关缺少文件和调试信息的更多消息可帮助您确定调试会话中缺少的内容。如果需要，返回到上一步骤。

   如果应用的调试信息可作为文件而不是软件包提供，请使用 symbolic -file 命令加载这个文件到 GDB 中：

   (gdb) symbol-file program.debug

   使用实际文件名替换 program.debug。

   注意

   可能不需要为核心转储中包含的所有可执行文件安装调试信息。这些可执行文件的大部分是应用代码使用的库。这些库可能不会直接导致您要分析的问题，您不需要为它们包含调试信息。

6. 在应用崩溃时，使用 GDB 命令检查应用的状态。请参阅使用 GDB 检查应用内部状态。

   注意

   分析核心文件时，GDB 未附加到正在运行的进程。控制执行的命令无效。

流程

1. 根据可执行文件名称的已知部分，查找挂起进程的 PID：

   $ pgrep -a executable-name-fragment

   此命令将以以下形式输出一行：

   PID command-line

   使用 命令行 值验证 PID 是否属于预期进程。

   例如：

   $ pgrep -a bc

   5459 bc

2. 向进程发送中止信号：

   # kill -ABRT PID

3. 验证内核是否已由 coredumpctl 捕获：

   $ coredumpctl list PID

   例如：

   $ coredumpctl list 5459

   TIME                            PID   UID   GID SIG COREFILE  EXE
   Thu 2019-11-07 15:14:46 CET    5459  1000  1000   6 present   /usr/bin/bc

4. 根据需要进一步检查或使用 core 文件。

   您可以根据 PID 和其他值指定内核转储。详情请查看 coredumpctl(1) 手册页。

   • 显示核心文件的详细信息：

     $ coredumpctl info PID

   • 加载 GDB 调试器中的核心文件：

     $ coredumpctl debug PID

     根据调试信息的可用性，GDB 将建议运行的命令，例如：

     Missing separate debuginfos, use: dnf debuginfo-install bc-1.07.1-5.el8.x86_64

     有关此过程的详情，请参考 第 3.1.4 节 “使用 GDB 获取应用程序或库的 debuginfo 软件包”。

   • 导出核心文件以便在其他位置进行进一步处理：

     $ coredumpctl dump PID > /path/to/file_for_export

     使用您要放置内核转储的文件替换 /path/to/file_for_export。

流程

1. 查找进程 id(pid)。使用 ps、pgrep 和 top 等工具 ：

   $ ps -C some-program

2. 转储这个过程的内存：

   $ gcore -o filename pid

   这会创建 文件名，并转储其中的进程内存。在内存被转储时，进程的执行将被停止。

3. 内核转储完成后，进程会恢复正常执行。

4. 创建 SOS 报告以提供有关系统的更多信息：

   # sosreport

   这将创建一个 tar 存档，其中包含系统的相关信息，如配置文件副本。

5. 将程序的可执行文件、核心转储和 SOS 报告传送到要进行调试的计算机。
6. 可选：传输后删除核心转储和 SOS 报告，以释放磁盘空间。

流程

1. 将 GDB 设置为忽略 /proc/PID/coredump_filter 文件中的设置：

   (gdb) set use-coredump-filter off

2. 将 GDB 设置为忽略内存页面标记 VM_DONTDUMP ：

   (gdb) set dump-excluded-mappings on

3. 转储内存：

   (gdb) gcore core-file

   使用您要转储内存的文件名称替换 core-file。

1. 进入插件目录：

   # cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin

2. 创建符号链接：

   # ln -s annobin.so gcc-annobin.so

1. 进入插件目录：

   # cd /opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin

2. 创建符号链接：

   # ln -s annobin.so gcc-annobin.so

1. 进入插件目录：

   # cd /opt/rh/gcc-toolset-14/root/usr/lib/gcc/architecture-linux-gnu/14/plugin

2. 创建符号链接：

   # ln -s annobin.so gcc-annobin.so

1. 进入插件目录：

   $ cd /opt/rh/gcc-toolset-15/root/usr/lib/gcc/architecture-linux-gnu/15/plugin

2. 创建符号链接：

   $ ln -s annobin.so gcc-annobin.so

流程

1. 使用您的客户门户网站凭证访问 Red Hat Container Registry ：

   $ podman login registry.redhat.io

   Username: username
   Password: **

2. 以 root 用户身份运行相关命令来拉取所需的容器镜像：

   # podman pull registry.redhat.io/rhel8/gcc-toolset-<toolset_version>-toolchain

   将 toolset_version 替换为 GCC Toolset 版本，如 14。

   注意

   在 RHEL 8.1 及更新的版本中，您可以将您的系统设置为以非 root 用户身份使用容器。详情请参阅 设置 rootless 容器。

3. 可选：运行列出本地系统上所有容器镜像的命令，检查拉取是否成功：

   # podman images

4. 通过在容器内启动 bash shell 运行容器：

   # podman run -it image_name /bin/bash

   -i 选项创建一个交互式会话；如果没有此选项，shell 将打开并立即退出。

   t 选项打开终端会话；没有此选项，您就无法在 shell 中键入任何内容。

流程

1. 使用您的客户门户网站凭证访问 Red Hat Container Registry：

   $ podman login registry.redhat.io

   Username: username
   Password: **

2. 以 root 用户身份拉取容器镜像：

   # podman pull registry.redhat.io/rhel{ProductNumber}/gcc-toolset-14-toolchain

3. 以 root 用户身份使用交互式 shell 启动容器镜像：

   # podman run -it registry.redhat.io/rhel{ProductNumber}/gcc-toolset-14-toolchain /bin/bash

4. 按照预期运行 GCC Toolset 工具。例如，要验证 gcc 编译器版本，请运行：

   bash-4.4$ gcc -v

   ...
   gcc version 14.2.1 20240801 (Red Hat 14.2.1-1) (GCC)

5. 要列出容器中提供的所有软件包，请运行：

   bash-4.4$ rpm -qa