[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

Richard Osborne richard at xmos.com
Wed Jul 31 03:38:10 PDT 2013

On 25/07/13 18:54, Shankar Easwaran 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.
I'd like to see a more precise definition of "safe". For example just 
from the above description it is not clear that "safe" disallows one 
function falling through into another, but based on the intended use 
cases this clearly isn't allowed.

How is alignment handled? If I have two functions in the same section 
with different .align directives will these be respected when the 
section is split apart? Is it OK for a loop within a function to have a 

What about relocations? If calls are implemented with branches taking 
pc-relative offsets then the assembler might patch in the branch offset 
and not emit a relocation. This clearly prevents functions from being 
removed / reordered, so I assume it is a requirement that a safe section 
always uses relocations for branches between functions and if it has a 
choice of long or short branches it aways conservatively uses a long 
branch. This should be made explicit in the description of safe.

If you have a symbol at the same address as a function how do you decide 
if it should be associated with this function or the end of the last 

Is it a requirement that there are no references to symbols defined 
inside the function except for the function symbol itself? If so how 
does this work when you have debug info (which might have references to 
addresses within the function)?

Richard Osborne | XMOS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/7a9a124a/attachment.html>

More information about the llvm-dev mailing list