[LLVMdev] [PROPOSAL] ELF safe/unsafe sections

Eric Christopher echristo at gmail.com
Wed Jul 31 15:05:16 PDT 2013

>>> 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.


More information about the llvm-dev mailing list