[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Konstantin Tokarev]

31.07.2013, 07:49, "Shankar Easwaran" <shankare at codeaurora.org>:
> On 7/30/2013 7:50 PM, Eric Christopher wrote:
>
>>  On Tue, Jul 30, 2013 at 5:36 PM, Nick Kledzik <kledzik at apple.com> wrote:
>>>  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).
>>  I'll stipulate all of this :)
>>>  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.
>>  I'm not talking about using -ffunction-sections to determine if
>>  something is compiler generated, just that there's no inherent penalty
>>  in using -ffunction-sections in general. Basically there's no benefit
>>  (unless you allow a flag per object, etc) that says whether or not
>>  something is "compiler generated", you may as well just use a flag to
>>  the linker or a section in the output (the latter is a fairly common
>>  elf-ism).
>
> When you consider the complete link line (consisting of multiple
> archives and object files), you may not have all of them compiled with
> -ffunction-sections and -fdata-sections. Its also a problem that third
> party vendors would provide a library which may / may not be compiled
> with that flag.

You don't have to compile ALL sources with -ffunction-sections and -fdata-sections
in order to use --gc-sections in linker. You can freely miz object built with and
without one or both of these options in one link.

Moreover, you can even get some size savings (very small though) when using
--gc-sections without use of -ffunction-sections and -fdata-sections at all.

-- 
Regards,
Konstantin