[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Nick Kledzik]

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.

-Nick