1. 源文件是编译到对象文件中。
2. 对象文件和库已链接（包括之前编译的源）。

步骤

1. 更改到包含源代码文件的目录。

2. 使用 -c 选项运行 gcc ：

   $ gcc -c source.c another_source.c

   创建对象文件，其文件名反映了原始源代码文件： source.c 将生成 source.o。

   注意

   使用 C++ 源代码，将 gcc 命令替换为 g++ 以方便地处理 C++ 标准库依赖项。

步骤

1. 更改到包含对象代码文件的目录。

2. 运行 gcc ：

   $ gcc ... objfile.o another_object.o ... -o executable-file

   从提供的对象文件和库中创建一个名为 executable-file 的可执行文件。

   要链接附加库，请在对象文件列表后添加所需选项。

   注意

   使用 C++ 源代码，将 gcc 命令替换为 g++ 以方便地处理 C++ 标准库依赖项。

步骤

1. 创建一个目录 hello-c 并修改它：

   $ mkdir hello-c
   $ cd hello-c

2. 使用以下内容创建文件 hello.c ：

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

3. 使用 GCC 编译代码：

   $ gcc -c hello.c

   对象文件 hello.o 已创建。

4. 从对象文件中链接可执行文件 helloworld:

   $ gcc hello.o -o helloworld

5. 运行生成的可执行文件：

   $ ./helloworld
   Hello, World!

步骤

1. 创建一个目录 hello-cpp 并修改它：

   $ mkdir hello-cpp
   $ cd hello-cpp

2. 使用以下内容创建文件 hello.cpp ：

   #include <iostream>
   
   int main() {
     std::cout << "Hello, World!\n";
     return 0;
   }

3. 使用 g++ 编译代码：

   $ g++ -c hello.cpp

   对象文件 hello.o 已创建。

4. 从对象文件中链接可执行文件 helloworld:

   $ g++ hello.o -o helloworld

5. 运行生成的可执行文件：

   $ ./helloworld
   Hello, World!

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

2. 使用 foo 库的标头编译程序源文件：

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

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

3. 将程序与 foo 库链接：

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

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

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

   $ ./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
   # 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
   $ cd hellomake

2. 创建一个包含以下内容的 hello.c 文件：

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

3. 创建包含以下内容的 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 方法行必须以 tab 字符开头！在文档中复制以上文本时，剪切和粘贴过程可能会粘贴空格而不是制表符（tab）。如果发生这种情况，请手动纠正问题。

4. 运行 make ：

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

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

5. 运行可执行文件 hello ：

   $ ./hello
   Hello, World!

6. 运行 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 软件包，请按照 手动应用程序或库获取 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 软件包提供。要安装它并启用其使用：

      # dnf install mlocate
      # updatedb

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

   $ rpm -qf /usr/lib64/libz.so.1.2.7
   zlib-1.2.11-10.el8.x86_64

   输出提供了安装软件包（name:epoch-version.release.architecture 的形式）的详情。

   重要

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

   • 文件从当前配置中包管理工具不知道的包安装。
   • 该文件使用本地下载并手动安装的软件包进行安装。在这种情况下，无法自动决定合适的 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
    pid

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

2. 将 GDB 附加到此过程：

   $ gdb -p pid

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

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

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

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

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

   (gdb) attach pid

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

步骤

1. 识别要监控的系统调用。

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

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

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

   • 如果程序已在运行，找到其进程 ID(pid)并将 strace 附加到它：

     $ ps -C program
     (...)
     $ strace -fvttTyy -s 256 -e trace=call -ppid

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

3. strace 工具显示由应用发出的系统调用及其详情。

   在大多数情况下，应用程序及其库会立即出现大量调用和 strace 输出，如果没有设置系统调用的过滤器。

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

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

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

5. 分析应用所完成的系统调用列表。

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

步骤

1. 如果可能，请确定感兴趣的库和功能。

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

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

     $ ltrace -f -l library -e function program

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

     $ ps -C program
     (...)
     $ ltrace -f -l library -e function program -ppid

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

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

     如需更多信息，请参阅 ltrace(1)_ manual page。

3. ltrace 显示应用程序发出的库调用。

   在大多数情况下，如果没有设置任何过滤器，应用程序会立即显示大量调用和 ltrace 输出。

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

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

   • 如果 ltrace 启动程序，则程序会与 ltrace 一起终止。
   • 如果您将 ltrace 附加到已运行程序，则程序会与 ltrace 一起终止。

5. 分析应用所完成的库调用列表。

   • 如果应用程序崩溃，重要信息可能会在日志的末尾。
   • 输出中包含大量不必要的信息。但是，您可以构建更加精确的过滤器并重复这个过程。

步骤

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

   $ ps -aux

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

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

   pid 的值是进程 ID。

   脚本编译到内核模块中，然后载入该模块。这会在输入命令并获取输出之间引入小延迟。

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

步骤

1. 设置 catchpoint:

   (gdb) catch syscall syscall-name

   命令 catch syscall 设置了一个特殊的断点，它会在程序执行系统调用时停止执行。

   syscall-name 选项指定调用的名称。您可以为各种系统调用指定多个追踪点。使用 syscall-name 选项会使 GDB 在任意系统调用中停止。

2. 开始执行程序。

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

     (gdb) r

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

     (gdb) c

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

步骤

1. 设置 catchpoint:

   (gdb) catch signal signal-type

   命令 catch signal 设定一种特殊类型的断点，它会在程序收到信号时停止执行。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 而不是 unlimited 来运行 命令。

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

   # dnf install sos

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

6. 创建 SOS 报告以提供系统的附加信息：

   # sosreport

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

7. 查找并导出内核转储：

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

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

8. 将内核转储和 SOS 报告传送到进行调试的计算机。另外，也传输可执行文件（如果该文件已知）。

   重要

   当可执行文件未知时，然后对核心文件进行后续分析会标识它。

9. 可选：传输后删除内核转储和 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. 模块的可执行文件名称，如果未知显示为 -，如果模块没有从文件中加载则显示为 .。
   4. 调试信息的来源，在可用时显示为一个文件名，当包括在可执行文件本身中时显示为 .，或在不存在时显示 -
   5. 主模块的共享库名称(soname)或 [exe]

   在本例中，重要的细节是文件名 /usr/bin/sleep 以及在包括文本 [exe] 的行中的 build-id 2818b2009547f780a5639c904cded443e564973e。使用这些信息，您可以识别分析内核转储所需的可执行文件。

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

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

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

   有关缺失的文件和调试信息的进一步消息可帮助您识别调试会话中缺少什么。如果需要，返回到上一步。

   如果应用程序的调试信息可作为文件而不是软件包提供，使用 symbol-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. 可以根据需要进一步检查或使用核心文件。

   您可以根据 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

     有关此过程的详情，请参阅使用 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

   这会创建一个文件 filename 并转储进程内存。转储内存时，进程的执行将停止。

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。