GCC函数填充值 [英] GCC function padding value

问题描述

每当我在优化启用的情况下编译C或C ++代码时，d GCC将函数对齐到16字节的边界（在IA-32上）。如果函数的长度小于16个字节，GCC会为它填充一些字节，这似乎不是随机的：

  19：c3 ret 
 1a：8d b6 00 00 00 00 lea 0x0（％esi），％esi 
  

它似乎总是 8d b6 00 00 00 00 ... 或 8d 74 26 00 。

功能填充字节有什么意义吗？

解决方案

填充由汇编程序创建，而不是由gcc创建。它只是看到一个 .align 伪指令（或等价的），并不知道要填充的空间是在函数内部（例如循环对齐）还是在函数之间，所以它必须插入某种类型的 NOP s。现代x86汇编程序使用尽可能最大的 NOP 操作码，如果填充用于循环对齐，则意图花费尽可能少的周期。

就我个人而言，我非常怀疑对齐是一种优化技术。我从来没有看到过它有什么帮助，而且它可以通过极大地增加总代码大小（和缓存利用率）而受到伤害。如果您使用 -Os 优化级别，则默认情况下它是关闭的，所以没有什么可担心的。否则，您可以使用正确的 -f 选项禁用所有对齐。

Whenever I compile C or C++ code with optimizations enable,d GCC aligns functions to a 16-byte boundary (on IA-32). If the function is shorter than 16 bytes, GCC pads it with some bytes, which don't seem to be random at all:

19:   c3                      ret
1a:   8d b6 00 00 00 00       lea    0x0(%esi),%esi

It always seems to be either 8d b6 00 00 00 00 ... or 8d 74 26 00.

Do function padding bytes have any significance?

解决方案

The padding is created by the assembler, not by gcc. It merely sees a .align directive (or equivalent) and doesn't know whether the space to be padded is inside a function (e.g. loop alignment) or between functions, so it must insert NOPs of some sort. Modern x86 assemblers use the largest possible NOP opcodes with the intention of spending as few cycles as possible if the padding is for loop alignment.

Personally, I'm extremely skeptical of alignment as an optimization technique. I've never seen it help much, and it can definitely hurt by increasing the total code size (and cache utilization) tremendously. If you use the -Os optimization level, it's off by default, so there's nothing to worry about. Otherwise you can disable all the alignments with the proper -f options.

这篇关于GCC函数填充值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！