[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Shankar Easwaran]

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.
>
> 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.
>
> 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.
> 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.
> 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.

Shankar Easwaran