<div dir="ltr">On Tue, Jul 30, 2013 at 8:17 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank" class="cremed">shankare@codeaurora.org</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 7/30/2013 7:41 PM, Chandler Carruth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've not been following this thread at all. However, skimming the original<br>
post, I fail to find a nice summary of what problem is trying to be solved.<br>
</blockquote></div>
The proposal is trying to garbage collect symbols that are not referenced during the link step. In addition this proposal can be extended to keep frequently called functions/data closer to increase cache coherency.<br>
<br>
'lld' tries to atomize all the symbols in a section, but the problem it faces on ELF is that, lld needs to tie all the atoms in a section together to respect the ELF section property. This may be relaxed if lld knows at the time of parsing the section contents, that, if you really need to tie all the atoms together in the final ELF image.<br>

<br>
This proposal is just a way to convey information from the object file to the linker that  sections in the object file can be safely converted to atoms, and they need not be tied together in whichever section they reside.</blockquote>
<div><br></div><div>OK, thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
By reading the rest of the thread I divine that the goal is faster links<br>
and better dead code stripping?<br>
<br>
Making that clearer would help. Naming your sections something other than<br>
"safe" (which has *very* different connotations) would help more.<br>
</blockquote></div>
"safe" is a property of a section, by which a section can be atomized and the atoms can appear anywhere in the final output file.</blockquote><div><br></div><div>I don't think that this very narrow interpretation of "safe" is going to shared by anyone who hasn't read this email from you. ;] It would need a better name, but I'm not sure we need it at all, see below.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, I question several fundamental assumptions:<br>
1) We should be very certain that -ffunction-sections is not a viable<br>
solution as it exists and is well supported in other toolchains and<br>
environments.<br>
</blockquote></div>
-ffunction-sections and -fdata-sections would work, but that would require all third party libraries etc to make sure that they are all compiled with -ffunction-sections.</blockquote><div><br></div><div>Your proposal would require compiling all third party libraries with a compiler that supports safe sections.</div>
<div><br></div><div>The goal you have is *exactly* the goal of -ffunction-sections. We don't need another mechanism to solve this problem based on the criteria you have outlined here. Your proposal is also exactly the same complexity of deployment or implementation as -ffunction-sections in that it changes the fundamental output of the toolchain to make evident the separability of the units of the code.</div>
<div><br></div><div>Now, if there is a technical problem with putting functions in their own ELF sections, let's talk about that. But so far, I don't see anything even remotely compelling enough to talk about a special semantic change to certain sections.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) We should talk to other ELF producers and coordinate to make sure we<br>
don't end up creating a twisty maze of extensions here.<br>
</blockquote></div>
This is not a problem with the general ELF community since the binutils ld/gold would not atomize sections.</blockquote><div><br></div><div>Just because this won't actively explode with other ELF tools doesn't mean we shouldn't try to reach consensus throughout the larger community before changing the way in which Clang writes ELF files and LLD reads them. We really do need to maintain interoperability (by and large) with other toolchains on the same platform.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) We should step back and consider leapfrogging to a fully specialized<br>
format to reap even more performance benefits rather than messily patching<br>
ELF.<br>
</blockquote></div>
I dont think we should come up with another object file format.</blockquote><div><br></div><div>OK, there are others who disagree though. =] It is at least something that we shouldn't write off and should consider *IF* we're going to also consider the rest of the proposal. But currently, I think this entire thing already works with -ffunction-sections until there is a concrete description of why that mode simply won't work.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Shankar Easwaran<br>
</font></span></blockquote></div><br></div></div>