共享对象文件的大小很大

Question

我比较了三个编译器：

• Debian (6.3.0) 的 GCC (x86) 使用 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. 我怎样才能最好地分析目标文件中的差异？ （objdump、readelf 等）
2. 我怎样才能最好地分析编译器的差异（例如默认选项）？ （例如 -dumpspecs）
3. 炸毁共享对象的原因可能是什么？如何增加文件大小？

谢谢！

-- 编辑： 它也独立于 GCC 规范。我已经转储 (-dumpspec) Codesourcery (4.6.0) GCC 的规范，它生成一个小的共享对象，并将它与 Buildroot GCC (-specs) 一起使用，并再次获得一个 67K 的共享对象。

Answer 1

来自 :

It looks like this is due to binutils 2.27 increasing the default page size of PowerPC targets to 64k, resulting in bloated binaries on embedded platforms.

There's a discussion on the crosstool-NG github here.

Configuring binutils with --disable-relro should improve things.

You can also add -Wl,-z,max-page-size=0x1000 to gcc when compiling.

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