Add -Z no-unique-section-names to reduce ELF header bloat.

[jblazquez]

This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions.

By default, when enabling function sections (which is the default for most targets), the LLVM backend will generate different section names for each function. For example, a function func would generate a section called .text.func. Normally this is fine because the linker will merge all those sections into a single one in the binary. However, starting with LLVM 12, the backend will also generate unique section names for exception handling, resulting in thousands of .gcc_except_table.* sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion here). This can bloat the ELF headers and string table significantly in binaries that contain many functions.

The new option is analogous to Clang's -fno-unique-section-names, and instructs LLVM to generate the same .text and .gcc_except_table section for each function, resulting in a smaller final binary.

The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65,000) that it broke some existing ELF tools, which couldn't handle so many sections.

Here's our old binary:

$ readelf --sections old.elf | head -1
There are 71746 section headers, starting at offset 0x2a246508:

$ readelf --sections old.elf | grep shstrtab
  [71742] .shstrtab      STRTAB          0000000000000000 2977204c ad44bb 00      0   0  1

That's an 11MB+ string table. Here's the new binary using this option:

$ readelf --sections new.elf | head -1
There are 43 section headers, starting at offset 0x29143ca8:

$ readelf --sections new.elf | grep shstrtab
  [40] .shstrtab         STRTAB          0000000000000000 29143acc 0001db 00      0   0  1

The whole binary size went down by over 20MB, which is quite significant.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cjgillot (or someone else) soon.

Please see the contribution instructions for more information.

[jblazquez]

I didn't use parse_no_flag - unlike the other no_* flags above - because the parse_no_flag function says its use is deprecated, so I made it a plain bool. Also, not entirely sure what tracking is for, so I set it to [TRACKED] because function_sections is also tracked.

[Mark-Simulacrum]

This seems pretty reasonable. Is there a reason we shouldn't enable this by default? It seems like the general approach should be that if it makes your binary smaller, since it prevents dead section elimination but otherwise is beneficial. Is that right?

It would be good to add a page to the unstable book in this PR https://github.com/rust-lang/rust/tree/master/src/doc/unstable-book/src/compiler-flags with some appropriate links and details on this.

[jblazquez]

I'm basing the defaults on what Clang does, and wasn't comfortable changing the default behavior for all ELF targets.

Clang (and LLVM) default to -funique-section-names (that is, do generate unique section names), presumably because if you use a .gcc_except_table-aware linker then you can get smaller binaries when passing it --gc-sections, since the linker understands it can remove the unreferenced EH sections of the stripped functions as well.

So to clarify, my understanding is that if you use the GNU ld linker, you want unique section names so --gc-sections makes the binary smaller. But if you use another linker, you want non-unique sections names to make the ELF headers smaller.

Do you think rustc should deviate from Clang here and default to -fno-unique-section-names?

[Mark-Simulacrum]

I don't think we should change the behavior in this PR, mostly wanted to get a read on whether it would make sense to in the future.

[jblazquez]

Sounds good. I'll get working on the unstable book page.

[jblazquez]

I added documentation for the new flag.

[cjgillot]

r? @Mark-Simulacrum

[Mark-Simulacrum]

Thanks. This looks basically good to go -- could you file a tracking issue (just a regular issue with a pointer to the future docs and a link to this PR is good) and list it in the unstable book entry?

r=me with that done (please use @rustbot ready to update labels)

[jblazquez]

Thanks Mark, I created the issue here: #90275

@rustbot ready

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 4ed846a has been approved by Mark-Simulacrum