[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Shankar Easwaran]

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/a27d5d58/attachment.html>