[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
Richard Osborne
richard at xmos.com
Wed Jul 31 14:35:44 PDT 2013
On 31 Jul 2013, at 16:32, Shankar Easwaran <shankare at codeaurora.org> wrote:
> 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.
Thanks for your answers :)
>
> 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?
Yes, if one function fell through into another it wouldn't be valid to put them in separate sections either. I was just trying to pin down the meaning 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 function?
> Are you talking about weak symbols here?
I was thinking about DWARF which, IIRC uses references to symbols in various places to mark the beginning and end (one past the last byte) of various entities. If multiple entities are placed in the same ELF section then, at least without making some assumptions, you can't tell the difference between a symbol pointing to the end of one entity and a symbol pointing to the start of the next. However if the entities are placed in different ELF sections you can use the symbol's section index to differentiate between the two cases.
>>
>> 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.
Is there a write-up about how this works / is going to work? If I go to http://lld.llvm.org/design.html it says:
"Currently, the lld model says nothing about debug info. But the most popular debug format is DWARF and there is some impedance mismatch with the lld model and DWARF"
Is there any progress on this? Would the same mechanism be used for other cases where you might have references to symbols in the middle of a function (e.g. for jump tables / computed gotos).
More information about the llvm-dev
mailing list