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
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).
>>> 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. >Ideally these are going to be local symbols that won't be externally visible so that lld's atomizing code won't see them. And yes, I'd have thought that -ffunction-sections would just ensure trivialness of that atomizing code. Just needs to be done on a per section basis.>>> >>> 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). >I'm rather curious what people are thinking of for the lld model here, I hadn't realized it was a concern. -eric