[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

Nick Kledzik kledzik at apple.com
Tue Jul 30 17:36:40 PDT 2013

On Jul 30, 2013, at 4:28 PM, Eric Christopher wrote:
> On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> wrote:
>> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote:
>>> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF section.
>> From my understanding, -ffunction-sections is a good semantic match.  But it introduces a lot of bloat in the .o file which the linker must process.
> Drive by comment here:
> Other than the overhead of the section header I'm not sure what bloat
> you're talking about here that the linker needs to process?

The internal model of lld is "atom" based.  Each atom is an indivisible run of bytes.  A compiler generated function naturally matches that and should be an atom.  The problem is that a hand written assembly code could look like it has a couple of functions, but there could be implicit dependencies (like falling through to next function). 

If an object file has a hundred functions, that means there will be a hundred more sections (one per function).    So, if we used -ffunction-sections to determine that an object file was compiler generated, we still have the problem that an assembly language programmer could have hand written extra sections that look like -ffunction-sections would have produced, but he did something tricky like have one function with two entry symbols.  So, the linker would need to double check all those hundred sections.


More information about the llvm-dev mailing list