[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Chandler Carruth]

On Tue, Jul 30, 2013 at 8:17 PM, Shankar Easwaran
<shankare at codeaurora.org>wrote:

> On 7/30/2013 7:41 PM, Chandler Carruth wrote:
>
>> I've not been following this thread at all. However, skimming the original
>> post, I fail to find a nice summary of what problem is trying to be
>> solved.
>>
> 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.
>
> '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.
>
> 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.


OK, thanks.


>
>
>> By reading the rest of the thread I divine that the goal is faster links
>> and better dead code stripping?
>>
>> Making that clearer would help. Naming your sections something other than
>> "safe" (which has *very* different connotations) would help more.
>>
> "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.


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.


>
>
>> However, I question several fundamental assumptions:
>> 1) We should be very certain that -ffunction-sections is not a viable
>> solution as it exists and is well supported in other toolchains and
>> environments.
>>
> -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.


Your proposal would require compiling all third party libraries with a
compiler that supports safe sections.

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.

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.


 2) We should talk to other ELF producers and coordinate to make sure we
>> don't end up creating a twisty maze of extensions here.
>>
> This is not a problem with the general ELF community since the binutils
> ld/gold would not atomize sections.


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.


>
>  3) We should step back and consider leapfrogging to a fully specialized
>> format to reap even more performance benefits rather than messily patching
>> ELF.
>>
> I dont think we should come up with another object file format.


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.


>
>
> Shankar Easwaran
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/ce3a9f71/attachment.html>