[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

[Shankar Easwaran]

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.

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation