[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Shankar Easwaran]

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