Support dead-stripping in ELF objects

[Shankar Easwaran]

On 4/2/2013 8:23 PM, Michael Spencer wrote:
> 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.
Is this to deal with weak symbols ?
>    * For each symbol, st_value + st_size shall be the st_value of another
> symbol, or sh_size (the end of the section).
This wouldnot handle the case for hand coded assembly files, where the 
user forgets about specifying the size of the function
(Not  a requirement though). This also doesnot handle the case when 
symbols in the section are aligned differently.
>    * For each symbol, the range [st_value, st_value + st_size) shall be
> non-overlapping.
What if the symbol is 0 sized ? the next symbol and the current symbol 
will be overlapping right ?
>    * 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.
Isnt this same as the functionality that you get by using 
-ffunction-sections/-fdata-sections ?
>
> * 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.
When will this be used ?

I think this is duplicate of what -ffunction-sections/-fdata-sections 
will provide. You can dead strip a section
and the symbols contained in it, since the compiler has created a 
seperate section for that.
>
>    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
The linker will save space only if SHF_SUBSECTION_VIA_SYMBOLS is set, 
which otherwise doesnot get any benefit right ?

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation