不同GCC编译的共享对象文件体积差异分析及技术咨询

Great questions—let's break down each one based on your observations with those PPC and x86 GCC toolchains:

1. How to best analyze object file differences with objdump and readelf? #

The key is to focus on section structure and padding since you already identified that as the source of the size gap. Here's what works best:

• List and compare sections: Run readelf -S your.so for each library—this shows every section's size, offset, alignment, and flags. Pipe the output to sort -k3n to sort sections by size, and you’ll immediately spot if oversized padding or unexpectedly large sections are the issue.
• Dump specific section content: Use objdump -s -j SECTION_NAME your.so to inspect the raw bytes of suspicious sections. For padding, check gaps between sections (look for blocks of zeros) or sections like .note.gnu.build-id which sometimes have extra alignment padding.
• Normalize and diff: Generate clean outputs with readelf -W -S hugo.so > so1.txt and the same for the smaller library, then run diff so1.txt so2.txt to see exact differences in section headers, alignment values, or sizes.
• Check linker alignment flags: readelf -l your.so (load segment info) will show the alignment requirements of each loadable segment—if one library uses a much larger page alignment (like 64KB vs 4KB), that’s a dead giveaway for padding bloat.

2. How to analyze compiler differences (like default options) using dumpspecs and other tools? #

dumpspecs is useful, but you’ll want to combine it with other commands to get the full picture:

• Inspect linker specs: Run powerpc-linux-gcc -dumpspecs and search for sections starting with *link_command—this shows how GCC constructs the linker command line by default. Look for differences in alignment flags (-z max-page-size), linker scripts, or padding-related options.
• See full implicit flags: Use powerpc-linux-gcc -v --shared -o hugo.so hugo.o—this prints every flag GCC passes to the linker, including any default linker scripts it’s using. Compare these across toolchains to spot alignment or section handling differences.
• Extract default linker scripts: Run powerpc-linux-ld --verbose to get the linker’s default script. Check the SECTIONS block for alignment directives (like . = ALIGN(0x10000); for 64KB alignment)—if Buildroot’s linker uses a larger alignment here, that’s why your SO is bigger.
• Check compiler defaults: powerpc-linux-gcc -v -c hugo.c shows flags passed to the compiler front-end, but since your issue is linking-related, focus on the linker output from the previous step.

3. Why is the shared object size spiking so much? #

Based on your padding observation and the fact that swapping specs didn’t fix it, the root cause is almost certainly enforced large section/segment alignment from Buildroot’s PPC toolchain:

• Many embedded PPC systems use large page sizes (like 64KB), and Buildroot might configure its toolchain to align all loadable segments to this page size by default. Your tiny .text and .data sections take up just a few hundred bytes, but the linker pads them out to fill a full 64KB page (plus any additional segment alignment gaps), leading to the 67KB size.
• Unlike the Codesourcery or Debian toolchains, which might use a smaller default alignment (like 4KB) for shared libraries, Buildroot’s toolchain prioritizes compatibility with target hardware over minimal size.
• It’s not GCC specs causing this—since swapping specs didn’t help, the issue is in the linker configuration or default linker script that comes with Buildroot’s toolchain.

4. How to intentionally increase shared object size? #

If you want to bulk up an SO for testing or specific use cases, try these methods:

• Force large alignment: Add -Wl,-z,max-page-size=65536 to your linker command—this tells the linker to align all loadable segments to 64KB, adding massive padding between small sections.
• Add explicit padding sections: Insert a zero-initialized array in a custom section in your code:

  __attribute__((section(".custom_padding"))) char big_padding[100000] = {0};
  

• Disable section optimizations: Use -fno-merge-constants to prevent the compiler from merging duplicate constants, or -Wl,--no-merge-exidx-entries (PPC-specific) to stop the linker from merging sections.
• Include debug info: Compile with -g and skip stripping the binary (strip hugo.so removes debug sections)—this adds significant size from debug symbols, though it’s not padding-based.

内容的提问来源于stack exchange，提问作者Charly