[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
shankare at codeaurora.org
Tue Jul 30 20:17:50 PDT 2013
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
'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
> 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
-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
I dont think we should come up with another object file format.
More information about the llvm-dev