[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
shankare at codeaurora.org
Wed Jul 31 08:32:12 PDT 2013
Thanks for your very detailed analysis. From other email conversations,
it looks like -ffunction-sections and -fdata-sections are doing what is
being iterated in the original proposal.
On 7/31/2013 5:38 AM, Richard Osborne wrote:
> 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.
Doesnt this break the model even with ELF, For example if the code would
have been compiled with -ffunction-sections, the fall through into
another would just happen by chance when the linker merges similiar
sections together ?
> 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 .align?
Yes alignment is handled, Each atom has a seperate alignment which is
derived from the position where the atom was in the section and the
alignment of the section itself.
> 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.
Yes you are right.
> 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 function?
Are you talking about weak symbols here ?
> 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)?
The model needs to read the debug information that corresponds to the
function and keep them housed within the atom data structure itself.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
More information about the llvm-dev