[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Rui Ueyama]

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