共享对象文件的大小是巨大的

Question

我比较了三个编译器：

• 来自Debian的GCC（x86）（6.3.0）以 7.8K 生成hugo_x86.so，
来自Codesourcery（4.6.0）的
• GCC（ppc）以 6.6K 生成hugo_46.so，
• 来自Buildroot 2017.08（7.2.0）的GCC（x86）以 7.5K 生成hugo.so，
• 来自Buildroot 2017.08（7.2.0）的GCC（ppc）以 67K 生成hugo.so，
• 来自Buildroot 2017.08（6.4.0）的GCC（ppc）以 67K 和
生成hugo.so
• 来自Buildroot 2017.08（4.9.4）的GCC（ppc）以 67K 生成hugo.so

代码取自eli.thegreenplace.net：

int myglob = 42;

int ml_func(int a, int b)
{
    myglob += a;
    return b + myglob;
}

我编译了所有这样的来源：

powerpc-linux-gcc -c -o hugo.o hugo.c
powerpc-linux-gcc --shared -o hugo.so hugo.o

文件之间的区别似乎是填充（hexdump hugo.so | wc -l）：

• Debian（6.3.0）： 381行
• Codesourcery（4.6.0）： 283行
• Buildroot 2017.08（7.2.0）： 298行
• Buildroot 2017.08（6.4.0）： 294行

（objdump -s显示类似的结果）

问题：

1. 如何最好地分析Object文件中的差异？ （objdump，readelf等）
2. 如何最好地分析编译器的差异（例如默认选项）？ （例如-dumpspecs）
3. 炸毁共享对象的原因是什么？如何增加文件大小？

谢谢！

- 修改 它也独立于GCC规范。我抛弃了（-dumpspec）代码源（4.6.0）GCC的规范，它产生了一个小的共享对象，并将它与Buildroot GCC（-specs）一起使用，并再次获得了一个67K的共享对象。

Answer 1

来自How to reduce ELF section padding?：

  

看起来这是因为binutils 2.27将PowerPC目标的默认页面大小增加到64k，导致嵌入式平台上出现臃肿的二进制文件。

     

这里有关于crosstool-NG github的讨论。

     

使用--disable-relro配置binutils可以改善一切。

     

您还可以在编译时将-Wl，-z，max-page-size = 0x1000添加到gcc。

将BR2_BINUTILS_EXTRA_CONFIG_OPTIONS="--disable-relro"添加到我的buildroot配置时，共享对象的大小会减少。