Support dead-stripping in ELF objects

Michael Spencer bigcheesegs at gmail.com
Tue Apr 2 18:23:47 PDT 2013


On Thu, Mar 21, 2013 at 11:13 AM, Robinson, Paul
<Paul.Robinson at am.sony.com>wrote:

> A while back I implemented some private changes to how relocations
> were handled in the ELF object writer, so that our linker could
> support dead-stripping.  Apparently MachO has a similar feature, so I
> leveraged some of what was done for that target, including reusing the
> assembler flag/directive.
>
> I'm told that there may be broader interest in supporting
> dead-stripping in ELF objects, so here's the patch.
>
> There is currently no in-tree ELF-using target that invokes this
> stuff; I'm putting it out there so anyone who's interested can take
> advantage of it in their own target/toolchain.
>
> Please review, and commit for me if it's okay.
>
> Thanks,
> --paulr
>

This is a good idea, but I think we need more for an effective and portable
implementation.

We need a detailed specification of what guarantees the compiler is making
for the linker. I've thought about this in terms of both deadstripping and
how to make atomization of ELF files faster and have the following:

Section flags:
* SHF_VALID_SIZE
  * There shall be a symbol with st_value of 0.
  * For each symbol, st_value + st_size shall be the st_value of another
symbol, or sh_size (the end of the section).
  * For each symbol, the range [st_value, st_value + st_size) shall be
non-overlapping.
  * If a relocation in this section has a target symbol which is in a
section with this flag set, r_addend must be less than st_size.

  This is separate from SHF_SUBSECTION_VIA_SYMBOLS because it makes
atomization faster even in cases where symbol data cannot be moved. This is
important as it allows the assembler to preform more relaxation to get
smaller output while still allowing for this optimization.

* SHF_SUBSECTION_VIA_SYMBOLS - SHF_VALID_SIZE must also be set.
  * The range [st_value, st_value + st_size) of each symbol in the section
may be moved to a different relative location.

* SHF_DEADSTRIP - This section may be removed if it is dead. If
SHF_SUBSECTION_VIA_SYMBOLS is also set, symbols and their data may be
removed if dead.

  This is separate because the assembler may have preformed relaxation
within a section, but you would still like the entire section to be removed
if it is not referenced. This also provides a way to limit the effect of
--gc-sections without hard coding the names of sections not to remove (such
as .init and .fini).

Symbol flags (which we'll have to find a place to embed, probably st_other
which has 6 free bits):
* STF_NO_DEADSTRIP - Never remove this symbol or symbols it references even
if it is in a SHF_SUBSECTION_VIA_SYMBOLS or SHF_DEADSTRIP section.


== Deadstripping ==

The deadstrip roots is the set of all symbols defined in sections not
marked SHF_DEADSTRIP, symbols with STF_NO_DEADSTRIP, and any implementation
defined symbols.

A symbol is live if it is a deadstrip root, or it is referenced from a
deadstrip root or another live symbol, or it is in a section not
marked SHF_SUBSECTION_VIA_SYMBOLS that has other live symbols.

A symbol X is referenced by Z if:
* If Z and X are not in a section marked SHF_VALID_SIZE.
  * There is a relocation in the section containing Z with a resolved
symbol which comes from the same file and has the same st_shndx as X (the
section containing Z references the section containing X).
* If Z is not in a section marked SHF_VALID_SIZE but X is.
  * There is a relocation in the section containing Z with the resolved
symbol X.
* If both Z and X are in sections marked SHF_VALID_SIZE.
  * There is a relocation with an r_offset within the range [st_value,
st_value + st_size) of Z with the resolved symbol X.

Any symbol that is not live may be removed if allowed by section flags.

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130402/ba6a0461/attachment.html>


More information about the llvm-commits mailing list