<div dir="ltr"><div class="gmail_extra"><div>On Thu, Mar 21, 2013 at 11:13 AM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul.Robinson@am.sony.com" target="_blank">Paul.Robinson@am.sony.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">A while back I implemented some private changes to how relocations<br>

were handled in the ELF object writer, so that our linker could<br>
support dead-stripping.  Apparently MachO has a similar feature, so I<br>
leveraged some of what was done for that target, including reusing the<br>
assembler flag/directive.<br>
<br>
I'm told that there may be broader interest in supporting<br>
dead-stripping in ELF objects, so here's the patch.<br>
<br>
There is currently no in-tree ELF-using target that invokes this<br>
stuff; I'm putting it out there so anyone who's interested can take<br>
advantage of it in their own target/toolchain.<br>
<br>
Please review, and commit for me if it's okay.<br>
<br>
Thanks,<br>
--paulr<br></blockquote><div><br></div><div style>This is a good idea, but I think we need more for an effective and portable implementation.</div><div style><br></div><div style>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:</div>
<div style><br></div><div style>Section flags:</div><div style>* SHF_VALID_SIZE</div><div style>  * There shall be a symbol with st_value of 0.</div><div style>  * For each symbol, st_value + st_size shall be the st_value of another symbol, or sh_size (the end of the section).</div>
<div style>  * For each symbol, the range [st_value, st_value + st_size) shall be non-overlapping.</div><div style>  * 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.<br>
</div><div style><br></div><div style>  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.</div>
<div style><br></div><div style>* SHF_SUBSECTION_VIA_SYMBOLS - SHF_VALID_SIZE must also be set.</div><div style>  * The range [st_value, st_value + st_size) of each symbol in the section may be moved to a different relative location.</div>
<div style><br></div><div style>* 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.</div><div style><br></div><div style>  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).</div>
<div style><br></div><div style>Symbol flags (which we'll have to find a place to embed, probably st_other which has 6 free bits):</div><div style>* 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.</div>
<div style><br></div><div style><br></div><div style>== Deadstripping ==</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>A symbol X is referenced by Z if:</div><div style>* If Z and X are not in a section marked SHF_VALID_SIZE.</div><div style>  * There is a relocation in the section containing Z with a resolved symbol which comes from the same file and has the same <span style="color:rgb(0,0,0)">st_shndx</span> as X (the section containing Z references the section containing X).<br>
</div><div style>* If Z is not in a section marked SHF_VALID_SIZE but X is.</div><div style>  * There is a relocation in the section containing Z with the resolved symbol X.</div><div style>* If both Z and X are in sections marked SHF_VALID_SIZE.</div>
<div style>  * There is a relocation with an r_offset within the range [st_value, st_value + st_size) of Z with the resolved symbol X.</div><div style><br></div><div style>Any symbol that is not live may be removed if allowed by section flags.</div>
<div style><br></div><div style>- Michael Spencer<br></div><div> </div></div></div></div>