[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
richard at xmos.com
Wed Jul 31 03:38:10 PDT 2013
On 25/07/13 18:54, Shankar Easwaran wrote:
> 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...
More information about the llvm-dev