Executable file size comparison

I compiled a program and standard library using clang/LLVM and found the
results interesting:

   text data bss dec hex filename
141312 4076 16668 162056 27908 bzip2.arm
131764 4076 16668 152508 253bc bzip2.armv7
134748 4048 16624 155420 25f1c bzip2.i386
259112 4028 16732 279872 44540 bzip2.microblaze
168044 4040 16816 188900 2e1e4 bzip2.mips
167860 4040 16816 188716 2e12c bzip2.mips32r2
179032 4040 16816 199888 30cd0 bzip2.mips32r2elsf
179008 4040 16816 199864 30cb8 bzip2.mips32r2sf
168060 4040 16816 188916 2e1f4 bzip2.mipsel
156312 4028 16784 177124 2b3e4 bzip2.ppc
163572 10896 19280 193748 2f4d4 bzip2.ppc64
145443 4696 19368 169507 29623 bzip2.x86_64

The libraries were compiled with -O1 and the program was compiled with -O2.
The whole thing was statically linked. I verified that each executable was
correct by running the bzip2 test cases under QEMU.

It is interesting to see how the architecture (and maybe maturity of the code
generator) affects code size.

-Rich

What could be so different in ppc64 that causes "data" to be more than
twice the size than on any other platform?

Csaba

Csaba,

It turns out that most of the data space used by the ppc64 is for a little
table created for each function defined in the program. The table has two 64
bit pointers in it, one is the address of the function. This is how Linux
ppc64 executables are built: the table is used to indirectly call functions.
There are many of these little tables in the program because it is statically
linked with the standard library.

-Rich

Can you try with GCC? Does it present the same symptom (data more than
2x as large than other platforms)?

Csaba

Csaba,

I'm setting up the library for a gcc build now (for a friend). When I get that
going, I'll try to find a ppc64 version of gcc to test it. The beauty of
clang/LLVM is that I only need to build it once and I get all the targets. :slight_smile:

-Rich