如何删除未使用的 C/C++带有 GCC 和 ld 的符号？

Question

我需要严格优化可执行文件的大小（ARM 开发）并且 我注意到在我当前的构建方案（gcc + ld）中未使用的符号不会被删除。

对生成的可执行文件/库使用 arm-strip --strip-unneeded 不会改变可执行文件的输出大小（我不知道为什么，也许它只是可以' t）。

修改我的构建管道的方式是什么（如果存在），以便从结果文件中删除未使用的符号？

---

我什至不会想到这一点，但我当前的嵌入式环境不是很“强大”并且 即使从 2M 中节省 500K 也会带来非常好的加载性能提升。

更新：

不幸的是，我使用的当前gcc版本没有-dead-strip选项和-ffunction-sections。 .. + --gc-sections for ld 不会对结果输出产生任何显着差异。

我很震惊这甚至成为了一个问题，因为我确信 gcc + ld 应该自动删除未使用的符号（为什么他们甚至必须保留它们？）。

Answer 1

-fdata-sections -ffunction-sections -Wl,--gc-sections 最小示例分析

这些选项在以下位置提到：https://stackoverflow.com/a/6770305/895245 我只是想确认它们是否有效并检查一下如何使用objdump。

我们得出的结论与其他帖子提到的类似：

• 如果使用了某个部分的任何符号，则整个部分都会进入，即使根本没有使用其他一些符号，
• 内联也会使符号不被视为已使用
• -flto 会导致未使用的符号被删除，即使同一编译单元中使用了其他符号

单独文件，仅限 -O3

notmain.c

int i1 = 1;
int i2 = 2;

int f1(int i) {
    return i + 1;
}

int f2(int i) {
    return i + 2;
}

main.c

extern int i1;
int f1(int i);

int main(int argc, char **argv) {
    return f1(argc) + i1;
}

编译仅适用于 -O3：

gcc -c -O3 notmain.c
gcc -O3 notmain.o main.c

反汇编 notmain.o：

objdump -D notmain.o

输出包含：

Disassembly of section .text:

0000000000000000 <f1>:
   0:   f3 0f 1e fa             endbr64
   4:   8d 47 01                lea    0x1(%rdi),%eax
   7:   c3                      ret
   8:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
   f:   00

0000000000000010 <f2>:
  10:   f3 0f 1e fa             endbr64
  14:   8d 47 02                lea    0x2(%rdi),%eax
  17:   c3                      ret

Disassembly of section .data:

0000000000000000 <i2>:
   0:   02 00                   add    (%rax),%al
        ...

0000000000000004 <i1>:
   4:   01 00                   add    %eax,(%rax)
        ...

反汇编 notmain.o：

objdump -D a.out

输出包含：

Disassembly of section .text:

0000000000001040 <main>:
    1040:       f3 0f 1e fa             endbr64
    1044:       48 83 ec 08             sub    $0x8,%rsp
    1048:       e8 03 01 00 00          call   1150 <f1>
    104d:       03 05 c1 2f 00 00       add    0x2fc1(%rip),%eax        # 4014 <i1>
    1053:       48 83 c4 08             add    $0x8,%rsp
    1057:       c3                      ret
    1058:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
    105f:       00

0000000000001150 <f1>:
    1150:       f3 0f 1e fa             endbr64
    1154:       8d 47 01                lea    0x1(%rdi),%eax
    1157:       c3                      ret
    1158:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
    115f:       00

0000000000001160 <f2>:
    1160:       f3 0f 1e fa             endbr64
    1164:       8d 47 02                lea    0x2(%rdi),%eax
    1167:       c3                      ret

Disassembly of section .data:

0000000000004010 <i2>:
    4010:       02 00                   add    (%rax),%al
        ...

0000000000004014 <i1>:
    4014:       01 00                   add    %eax,(%rax)

结论 i2 和 f2 即使没有使用，也出现在最终的输出文件中。

即使我们添加了 -Wl,--gc-sections 来：

gcc -O3 -Wl,--gc-sections notmain.o main.c

尝试删除未使用的部分，也不会改变任何内容，因为在目标文件 notmain.o i2 与 i1 (.data) 出现在同一部分，f2 出现在同一部分作为f1 (.text)，它们已被使用，因此将其整个部分带入最终文件中。

-fdata-sections -ffunction-sections -Wl,--gc-sections

我们将编译命令修改为：

gcc -c -O3 -fdata-sections -ffunction-sections notmain.c
gcc -O3 -Wl,--gc-sections notmain.o main.c

反汇编 notmain.o:

objdump -D notmain.o

输出包含：

Disassembly of section .text.f1:

0000000000000000 <f1>:
   0:   f3 0f 1e fa             endbr64
   4:   8d 47 01                lea    0x1(%rdi),%eax
   7:   c3                      ret

Disassembly of section .text.f2:

0000000000000000 <f2>:
   0:   f3 0f 1e fa             endbr64
   4:   8d 47 02                lea    0x2(%rdi),%eax
   7:   c3                      ret

Disassembly of section .data.i2:

0000000000000000 <i2>:
   0:   02 00                   add    (%rax),%al
        ...

Disassembly of section .data.i1:

0000000000000000 <i1>:
   0:   01 00                   add    %eax,(%rax)

因此我们看到所有内容如何根据​​符号名称本身命名自己的部分。

反汇编 notmain.o：

objdump -D a.out

输出包含：

Disassembly of section .text:

0000000000001040 <main>:
    1040:       f3 0f 1e fa             endbr64
    1044:       48 83 ec 08             sub    $0x8,%rsp
    1048:       e8 03 01 00 00          call   1150 <f1>
    104d:       03 05 b5 2f 00 00       add    0x2fb5(%rip),%eax        # 4008 <i1>
    1053:       48 83 c4 08             add    $0x8,%rsp
    1057:       c3                      ret
    1058:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
    105f:       00

0000000000001150 <f1>:
    1150:       f3 0f 1e fa             endbr64
    1154:       8d 47 01                lea    0x1(%rdi),%eax
    1157:       c3                      ret

Disassembly of section .data:

0000000000004008 <i1>:
    4008:       01 00                   add    %eax,(%rax)

并且不包含 i2 和 f2。这是因为这次每个符号都在自己的部分中，因此 -Wl,--gc-sections 能够删除每个未使用的符号。

内联使符号不被视为已使用

为了测试内联的效果，让我们将测试符号移动到与 main.c 相同的文件中：

main2.c

int i1 = 1;
int i2 = 2;

int f1(int i) {
    return i + 1;
}

int f2(int i) {
    return i + 2;
}

int main(int argc, char **argv) {
    return f1(argc) + i1;
}

然后：

gcc -c -O3 main2.c
gcc -O3 -Wl,--gc-sections -o main2.out main2.o

反汇编 main2.o：

objdump -D main2.o

输出包含：

Disassembly of section .text:

0000000000000000 <f1>:
   0:   f3 0f 1e fa             endbr64
   4:   8d 47 01                lea    0x1(%rdi),%eax
   7:   c3                      ret
   8:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
   f:   00

0000000000000010 <f2>:
  10:   f3 0f 1e fa             endbr64
  14:   8d 47 02                lea    0x2(%rdi),%eax
  17:   c3                      ret

Disassembly of section .data:

0000000000000000 <i2>:
   0:   02 00                   add    (%rax),%al
        ...

0000000000000004 <i1>:
   4:   01 00                   add    %eax,(%rax)
        ...

Disassembly of section .text.startup:

0000000000000000 <main>:
   0:   f3 0f 1e fa             endbr64
   4:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # a <main+0xa>
   a:   8d 44 38 01             lea    0x1(%rax,%rdi,1),%eax
   e:   c3                      ret

有趣的是 main 位于单独的部分 .text.startup 上，可能是为了允许其余文本进行 GC 处理。

我们还看到 f1 在 lea 0x1(%rax,%rdi,1),%eax 上完全内联（直接加 1），而出于我不知道的原因了解 i1 仍用于 mov 0x0(%rip),%eax 待重定位，另请参阅：链接器是做什么的？反汇编main2.out后重定位就清楚了以下。

反汇编 main2.out：

objdump -D main2.out

输出包含：

Disassembly of section .text:

0000000000001040 <main>:
    1040:       f3 0f 1e fa             endbr64
    1044:       8b 05 c2 2f 00 00       mov    0x2fc2(%rip),%eax        # 400c <i1>
    104a:       8d 44 38 01             lea    0x1(%rax,%rdi,1),%eax
    104e:       c3                      ret
    104f:       90                      nop

Disassembly of section .data:

0000000000004008 <i2>:
    4008:       02 00                   add    (%rax),%al
        ...

000000000000400c <i1>:
    400c:       01 00                   add    %eax,(%rax)

并且 f1 和 f2 被完全删除，因为 f1 被内联并且因此不再标记为已使用，因此整个 .text 部分被删除。

如果我们强制 f1 不内联：

int __attribute__ ((noinline)) f1(int i) {
    return i + 1;
}

那么 f1 和 f2 都会出现在 main2.out 上。

不同目标文件的部分是独立的，即使它们具有相同的名称

显然，例如：

notmain2.c

int i3 = 3;
int i4 = 4;

int f3(int i) {
    return i + 3;
}

int f4(int i) {
    return i + 4;
}

然后：

gcc -c -O3 notmain.c
gcc -c -O3 notmain2.c
gcc -O3 -Wl,--gc-sections notmain.o notmain2.o main.c
objdump -D a.out

不包含f3和f4，尽管包含了 f1 和 f2，并且两者都不是名为 .text 的部分。

可能的缺点：-fdata-sections -ffunction-sections -Wl,--gc-sections：链接速度较慢

我们应该找到一些基准，但这很可能，因为当一个符号引用同一编译单元中的另一个符号时，需要进行更多的重定位，因为它们不再出现在独立部分中。

-flto 会导致符号被删除，即使使用了同一编译单元中的其他符号

此外，无论 LTO 是否会导致内联发生，都会发生这种情况。考虑：

notmain.c

int i1 = 1;
int i2 = 2;

int __attribute__ ((noinline)) f1(int i) {
    return i + 1;
}

int f2(int i) {
    return i + 2;
}

main.c

extern int i1;
int f1(int i);

int main(int argc, char **argv) {
    return f1(argc) + i1;
}

编译和反汇编：

gcc -c -O3 -flto notmain.c
gcc -O3 -flto notmain.o main.c
objdump -D a.out

反汇编包含：

Disassembly of section .text:

0000000000001040 <main>:
    1040:       f3 0f 1e fa             endbr64
    1044:       e8 f7 00 00 00          call   1140 <f1>
    1049:       83 c0 01                add    $0x1,%eax
    104c:       c3                      ret

0000000000001140 <f1>:
    1140:       8d 47 01                lea    0x1(%rdi),%eax
    1143:       c3                      ret

并且 f2 不存在。因此，即使使用了 f1，f2 也被删除了。

我们还注意到 i1 和 i2 消失了。编译器似乎认识到 i1 从未真正修改过，只是将其“内联”为常量 1：add $0x1,%eax 。

相关问题： GCC LTO 是否执行跨文件死代码消除？ 由于某种原因，如果使用 -O0 编译目标文件，则不会发生代码消除：为什么 GCC 不这样做使用 -O0 编译目标文件时是否可以使用 LTO 消除死代码？

在 Ubuntu 23.04 amd64、GCC 12.2.0 上测试。

Answer 2

建议遗留行为使用所有可选代码构建静态库，并将编译单元减少到容纳微小任务所需的最低限度（也建议作为 unix 设计中的模式）

当链接代码并指定静态库时（< code>.a 存档）链接器仅处理从初始 crt0.o 代码引用的所有已编译模块，并且无需任何分段编译代码即可实现此目的。

我们在代码中做到了这一点，获得的好处可能不是最佳的，但允许我们以良好的内存占用继续开发并节省大量未使用的代码，但永远不会出现诸如让编译器调查之类的问题。我总是使用这个引理：如果该功能不是必需的，则不要绑定它。

Answer 3

您可以在目标文件（例如可执行文件）上使用 strip 二进制文件来从中删除所有符号。

注意：它更改文件本身并且不创建副本。

Answer 4

虽然不严格涉及符号，但如果要考虑大小 - 始终使用 -Os 和 -s 标志进行编译。 -Os 优化生成的代码以获得最小可执行文件大小，-s 从可执行文件中删除符号表和重定位信息。

有时 - 如果需要小尺寸 - 使用不同的优化标志可能 - 也可能不 - 有意义。例如，切换 -ffast-math 和/或 -fomit-frame-pointer 有时甚至可以节省数十个字节。

Answer 5

strip --strip-unneeded 仅对可执行文件的符号表进行操作。它实际上并没有删除任何可执行代码。

标准库通过将所有函数拆分为单独的目标文件，然后使用 ar 组合起来，从而实现您想要的结果。如果您随后将生成的存档链接为库（即向 ld 提供选项 -l your_library），则 ld 将仅包含目标文件，因此包含实际使用的符号。

您还可能会找到对此类似问题 使用。

Answer 6

我不知道这是否有助于解决您当前的困境，因为这是最近的功能，但您可以以全局方式指定符号的可见性。在编译时传递 -fvisibility=hidden -fvisibility-inlines-hidden 可以帮助链接器稍后删除不需要的符号。如果您正在生成可执行文件（而不是共享库），则无需执行更多操作。

更多信息（以及例如库的细粒度方法）可在 GCC wiki 上找到。

Answer 7

来自 GCC 4.2.1 手册的 -fwhole-program 部分：

假设当前编译单元代表正在编译的整个程序。除了 main 和通过属性 externally_visible 合并的所有公共函数和变量，所有公共函数和变量都成为静态函数，并且在某种意义上会被过程间优化器更积极地优化。虽然此选项相当于对由单个文件组成的程序正确使用static关键字，但与选项--combine结合使用此标志可用于编译大多数较小规模的程序C 程序，因为函数和变量对于整个组合编译单元来说是本地的，而不是对于单个源文件本身而言。

Answer 8

答案是-flto。您必须将其传递给编译和链接步骤，否则它不会执行任何操作。

它实际上工作得非常好 - 将我编写的微控制器程序的大小减少到之前大小的 50% 以下！

不幸的是，它看起来确实有点问题——我有过一些没有正确构建的例子。这可能是由于我正在使用的构建系统（QBS；它非常新）造成的，但无论如何，我建议您仅在可能的情况下为最终构建启用它，并彻底测试该构建。

Answer 9

编程习惯也有帮助；例如，将 static 添加到不在特定文件外部访问的函数；使用较短的符号名称（可以有一点帮助，但可能不会太多）；尽可能使用 const char x[] ； ...本文虽然讨论了动态共享对象，但可以包含一些建议，如果遵循这些建议，可以提供帮助使最终的二进制输出大小更小（如果您的目标是 ELF）。

Answer 10

在我看来，尼莫提供的答案是正确的。如果这些说明不起作用，则问题可能与您使用的 gcc/ld 版本有关，作为练习，我使用详细说明编译了一个示例程序 here

#include <stdio.h>
void deadcode() { printf("This is d dead codez\n"); }
int main(void) { printf("This is main\n"); return 0 ; }

然后我使用逐渐更积极的死代码删除开关编译了代码：

gcc -Os test.c -o test.elf
gcc -Os -fdata-sections -ffunction-sections test.c -o test.elf -Wl,--gc-sections
gcc -Os -fdata-sections -ffunction-sections test.c -o test.elf -Wl,--gc-sections -Wl,--strip-all

这些编译和链接参数分别生成大小为 8457、8164 和 6160 字节的可执行文件，其中最重要的贡献来自“strip-all”声明。如果您无法在您的平台上产生类似的减少，那么您的 gcc 版本可能不支持此功能。我在 Linux Mint 2.6.38-8-generic x86_64 上使用 gcc(4.5.2-8ubuntu4)、ld(2.21.0.20110327)

Answer 11

如果要相信此帖子，您需要提供-ffunction-sections 和 -fdata-sections 到 gcc，它将把每个函数和数据对象放在自己的部分中。然后你给出 --gc-sections< /code>到 GNU ld 以删除未使用的部分。

Answer 12

您需要检查您的文档以了解您的 gcc 和 gcc 版本。 ld：

但是对我来说（OS X gcc 4.0.1）我找到了这些 ld

<前><代码>-dead_strip

删除入口点或导出符号无法访问的函数和数据。

<前><代码>-dead_strip_dylibs

删除入口点或导出符号无法访问的 dylib。也就是说，抑制在链接期间不提供符号的 dylib 生成加载命令命令。当链接到 dylib 时，不应使用此选项，因为某些间接原因（例如 dylib 有一个重要的初始值设定项）在运行时需要该 dylib。

这个有用的选项

<前><代码>-why_live symbol_name

记录对symbol_name的引用链。仅适用于-dead_strip。它可以帮助调试为什么您认为应该删除死条的东西没有被删除。

gcc/g++ man 中还有一个注释，只有在编译时启用优化时才会执行某些类型的死代码消除。

虽然这些选项/条件可能不适用于您的编译器，但我建议您在文档中查找类似的内容。

Answer 13

对于 GCC，这是通过两个阶段完成的：

首先编译数据，但告诉编译器将代码分成翻译单元内的单独部分。这将通过使用以下两个编译器标志来对函数、类和外部变量完成：

-fdata-sections -ffunction-sections

链接器优化标志将翻译单元链接在一起（这会导致链接器丢弃未引用的部分）：

-Wl,--gc-sections

使用 如果您的 cpp 中声明了两个函数，但其​​中一个未使用，您可以使用 gcc(g++) 的以下命令省略未使用的函数：（

gcc -Os -fdata-sections -ffunction-sections test.cpp -o test -Wl,--gc-sections

请注意，-Os 是一个附加编译器标志，告诉 GCC 优化大小）