[PATCH] sectiongroup support

[Shankar Easwaran]

Thanks Nick.

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 
--noinhibit-exec

(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 
chicken-egg problem.

I think the Native writer also would have this same issue, right ?

Thanks

Shankar Easwaran

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140317/a15f6f5f/attachment.html>