[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

Rui Ueyama ruiu at google.com
Thu Jul 25 13:56:00 PDT 2013


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"?
 - "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.
 - How about making the compiler to create a new section for each "safe"
atom, as it does for inline functions?


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


More information about the llvm-dev mailing list