[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Rui Ueyama]

Then how about enable these flags for -O2? I want to hear from other people
cc'ed, and I may be too cautious, but I'd hesitate to define a new ELF
section if there's other mean already available to achieve the same thing.


On Thu, Jul 25, 2013 at 2:12 PM, Shankar Easwaran
<shankare at codeaurora.org>wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130725/e7175329/attachment.html>