[PATCH] sectiongroup support
shankare at codeaurora.org
Mon Mar 17 15:48:58 PDT 2014
On 3/17/2014 5:22 PM, Nick Kledzik wrote:
> On Mar 15, 2014, at 10:02 PM, Shankar Easwaran
> <shankare at codeaurora.org <mailto:shankare at codeaurora.org>> wrote:
>> Hi Nick,
>> This is the overall design that I am working on to support
>> reading/resolving section groups in the YAML reader.
>> a) Read all atoms
>> b) any atoms with group-parent references are moved to
>> AtomList<lld::DefinedAtom> _groupChildAtoms;
>> c) There would also be a map _groupChildMap that has a key from
>> groupChild to groupParent, this is to support (d)
>> d) If there is a reference to a groupChild from another child(whose
>> parent is different from the previous group child), the groupChild
>> reference is changed to refer to a undefined atom for the groupChild
>> e) if there is a reference to a groupchild that doesnot have a
>> group-parent reference, and if the reference is not to a atom that is
>> undefined, create an undefinedatom and point the group child.
> It is not clear if you mean the ELF Reader will be doing this or the
> SymbolTable. I think any creation of UndefinedAtoms should be done in
> the ELF Reader to properly present the ELF file as atoms. The
> SymbolTable/Resolver just coalesce atoms and bind references.
I am initially planning to add support in core(ReaderWriterYAML).
>> *We could also do something where all groupchild references refer to
>> undefined atoms.*
>> *There seems to be a caveat even after everything looks sane.
>> a) There is a funny case of what do we do when the group child is a
>> local symbol ? So if there is a reference to a group child whose
>> scope is local, we cannot create a undefined reference to the group
>> child right ?
> From <http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter7-26.html>
> References to the sections comprising a group from sections
> outside of the group must be made through symbol table entries
> with STB_GLOBAL or STB_WEAK binding and section indexSHN_UNDEF. A
> definition of the same symbol in the object containing the
> reference must have a separate symbol table entry from the
> reference. Sections outside of the group can not reference symbols
> with STB_LOCAL binding for addresses that are contained in the
> group's sections, including symbols with type STT_SECTION.
> I read that as references to local symbol in a group can only come
> from other symbols in the group. It also sounds like the ELF file
> already have undefined symbols to reference definitions in a group.
This is nice, and thanks for the pointer.
>> *b) The problem is we call the RoundTripYAML reader/writer and the
>> RoundTripNative reader/writer, which happens to be called after the
>> resolver is called, which would create undefined references to atoms!.**
> The issue is that to support easy replacement, groups are purposely
> unresolved (non-canonical) in .o files. Normally, that is fine
> because they will be processed through the Resolver which will replace
> any undefines yielding a canonical atom graph. But RoundTripYAML (and
> maybe RoundTripNative) could regenerate the unresolved state which
> will not be sent through the resolver again, so the Writer or other
> Passes will see a non-canonical atom graph.
> The same issue arises if the linker is being using to merge .o files
> (-r mode). The resolver will produce a canonical graph (no extra
> undefines), but the ELF Writer will want them.
Yeah, yes you are right.
> I think the solution:
> 1) keep the existing canonical form for an atom graph that Passes process
> 2) make the ELF Writer smart that when it writes relocatable object
> files, to synthesize undefined symbols for references into group children
> 3) Have the YAML Reader be dumb and not synthesize any undefines.
> Test cases for groups that want undefines will need to explicitly
> have them in the yaml. This also enables you to write test cases that
> test the error case where an indirection though an undefine is not used.
The below steps as in the command line would not work though.
lld -flavor gnu -target x86_64 group.o --output-filetype=yaml
(Input file is processed by the ELF reader, convert the read files to
YAML files, re-read the files from YAML back into atoms)
As the YAML reader wouldnt synthesize undefined atoms ? Its like a
I think the Native writer also would have this same issue, right ?
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits