<div dir="ltr"><div class="gmail_extra"><div>On Tue, Apr 2, 2013 at 6:49 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.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"><div style="word-wrap:break-word"><div class="im">On Apr 2, 2013, at 6:23 PM, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>> wrote:<br>
</div><div><div class="im"><blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div class="gmail_extra"><div><br>
</div><div class="gmail_quote"><div>This is a good idea, but I think we need more for an effective and portable implementation.</div></div></div></div></div></blockquote></div><div>I very much agree!</div><div class="im">
<br><blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<br></div><div>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><br></div><div>Section flags:</div><div>* SHF_VALID_SIZE</div><div>  * There shall be a symbol with st_value of 0.</div><div>  * 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>  * For each symbol, the range [st_value, st_value + st_size) shall be non-overlapping.</div></div></div></div></div></blockquote></div><div>So these say that the whole section is "covered" by the set of symbol ranges.  Is that too strict?  What if the compiler 16-byte aligned the start of each function.  Should the padding at the end be included in each st_size?  If the padding is not in the st_size, then that would allow the linker optimizations like replacing the padding with small functions...</div>
</div></div></blockquote><div><br></div><div style>You're right, that is too strict. Non-overlapping is the main point.</div><div> </div><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">
<div style="word-wrap:break-word"><div><div class="im"><div><br></div><br><blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>  * 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></div>
</div></div></blockquote></div><div>I assume you mean the st_size of the target symbol.  But that would disallow valid C code.  You can write:</div><div><br></div><div>       char* x = &foo + 100;</div><div>or</div><div>
       char* y = &foo - 50;</div><div><br></div><div>where 100 > sizeof(foo).  Supporting this sort of stuff is why "scattered relocations" were created for mach-o long ago.  You see mach-o does not have RELA relocations (that is relocations with addends). Scattered relocations give you the final value and the symbol.  You can then subtract the two to get the addend.    Anyway, with addends, you don't need this st_size check.  </div>
<div><br></div><div>Which reminds me this additional information is not just about dead stripping it also enable ordering.  That is, when you link, you can pass the linker an ordered list of "hot" functions/data and the linker can rearrange the atoms to group the hot atoms together.  The end result is less paging and less dirty pages.  And that is how "scattered relocation" got its name (yes, "scattered" seems like increasing entropy, whereas order files are attempting to better organize the code.  But in someone's mind moving the functions at all was "scattering" them).</div>
<span class=""><font color="#888888"><div><br></div><div>-Nick</div></font></span></div></div></blockquote><div><br></div><div style>Jumping between objects is not valid in C or C++, it just happens to work. However, this should actually be allowed in SHF_VALID_SIZE, as the section is still stuck together, and you're guaranteed for this to be true at the ABI level. Where this actually does need to apply is SHF_SUBSECTIONS_VIA_SYMBOLS, as we can't make any guarantees about what content is going to be outside the object's boundaries.</div>
<div><br></div><div>- Michael Spencer </div></div><br></div></div>