[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Shankar Easwaran]

Not all users compile their code with -ffunction-sections and 
-fdata-sections.

This is to handle usecases when libraries use a mix of object files too.


On 7/25/2013 4: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.
>
>
> On Thu, Jul 25, 2013 at 2:01 PM, Shankar Easwaran
> <shankare at codeaurora.org>wrote:
>
>> On 7/25/2013 3:56 PM, Rui Ueyama wrote:
>>
>>> I think I share the goal with you to make the foundation for better
>>> dead-strip, so thank you for suggesting. I'm not sure if marking a section
>>> as a whole as "safe" or "unsafe" is the best approach, though. Some
>>> comments.
>>>
>>>    - If the compiler generated code is always "safe", and if we can
>>> distinguish it from hand-written assembly code by checking if there's a
>>> gap
>>> between symbols, can we just assume a section with no gap is always
>>> "safe"?
>>>
>> Gaps could just be caused due to alignment, but the code may be safe,
>> which the compiler knows very well.
>>
>>
>>     - "Safeness" is not an attribute of the section but of the symbol, I
>>> think. The symbol is "safe" if there's no direct reference to the symbol
>>> data. All references should go through relocations. A section may contain
>>> both "safe" and "unsafe" symbols.
>>>
>> Sections contain symbols. In the context of ELF, marking sections as
>> safe/not is more desirable because of the switches (-ffunction-sections and
>> -fdata-sections available already).
>>
>>
>>     - How about making the compiler to create a new section for each "safe"
>>> atom, as it does for inline functions?
>>>
>> You already have a switch called -ffunction-sections and -fdata-sections
>> to put function and data in seperate sections.
>>
>>
>>> On Thu, Jul 25, 2013 at 10:54 AM, Shankar Easwaran
>>> <shankare at codeaurora.org>**wrote:
>>>
>>>     Hi,
>>>> Currently lld ties up all atoms in a section for ELF together. This
>>>> proposal just breaks it by handling it differently.
>>>>
>>>> *This requires **NO ELF ABI changes.
>>>>
>>>> **Definitions :-*
>>>>
>>>>
>>>> A section is not considered safe if there is some code that appears to be
>>>> present between function boundaries (or) optimizes sections to place data
>>>> at the end or beginning of a section (that contains no symbol).
>>>>
>>>> A section is considered safe if symbols contained within the section have
>>>> been associated with their appropriate sizes and there is no data present
>>>> between function boundaries.
>>>>
>>>> Examples of safe sections are, code generated by compilers.
>>>>
>>>> Examples of unsafe sections are, hand written assembly code.
>>>>
>>>> *Changes Needed :-*
>>>>
>>>>
>>>> The change that I am trying to propose is the compiler emits a section,
>>>> called (*.safe_sections) *that contains section indices on what sections
>>>>
>>>> are safe.
>>>>
>>>> The section would have a SHF_EXCLUDE flag, to prevent other linkers from
>>>> consuming this section and making it to the output file.
>>>>
>>>> Data structure for this :-
>>>>
>>>> .safe_sections
>>>> <total size>
>>>> <section index> <boolean flag -- safe/unsafe>
>>>> ...
>>>> ...
>>>>
>>>>
>>>> *Advantages
>>>> *There are advantages that the atoms within a safe section could just be
>>>>
>>>> allocated in the output file which means better output file layout, and
>>>> Better performance!
>>>>
>>>> This would also result in more atoms getting gc'ed.
>>>>
>>>> a) looking at profile information
>>>> b) taking a order file
>>>>
>>>> *Changes needed in the assembler
>>>>
>>>> *a) add an additional flag in the section for people writing assembly
>>>>
>>>> code, to mark a section safe or unsafe.
>>>> *
>>>> **Changes needed in lld
>>>>
>>>> *a) Read the safe section if its present in the object file
>>>>
>>>> b) Tie atoms together within a section if the section is not safe
>>>> *
>>>> *Thanks
>>>>
>>>> Shankar Easwaran*
>>>>
>>>> *
>>>>
>>>> --
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>>> hosted by the Linux Foundation
>>>>
>>>>
>>>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by the Linux Foundation
>>
>>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation