<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Thanks Nick.<br>
<br>
On 3/17/2014 5:22 PM, Nick Kledzik wrote:<br>
</div>
<blockquote
cite="mid:AF0C5235-C9B3-4E27-8640-053EE3D7015E@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On Mar 15, 2014, at 10:02 PM, Shankar Easwaran <<a
moz-do-not-send="true" href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Nick,<br>
<br>
This is the overall design that I am working on to support
reading/resolving section groups in the YAML reader.<br>
<br>
a) Read all atoms<br>
b) any atoms with group-parent references are moved to
AtomList<lld::DefinedAtom> _groupChildAtoms;<br>
c) There would also be a map _groupChildMap that has a key
from groupChild to groupParent, this is to support (d)<br>
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<br>
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.<br>
</div>
</div>
</blockquote>
<div>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.</div>
<div><br>
</div>
</div>
</blockquote>
I am initially planning to add support in core(ReaderWriterYAML).<br>
<br>
<blockquote
cite="mid:AF0C5235-C9B3-4E27-8640-053EE3D7015E@apple.com"
type="cite">
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><b>We could also do something
where all groupchild references refer to undefined
atoms.</b><br>
<br>
<b>There seems to be a caveat even after everything looks
sane.<br>
<br>
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 ?<br>
</b></div>
</div>
</blockquote>
<div>From <<a moz-do-not-send="true"
href="http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter7-26.html">http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter7-26.html</a>></div>
<div>
<ul style="margin-left: 13px; padding-left: 0px; font-family:
Arial, Helvetica, Luxi-sans, 'Nimbus Sans L', sans-serif;
font-size: 14px; background-color: rgb(255, 255, 255);">
<li style="margin-left: 13px; padding-left: 0px;
list-style-image:
url(http://docs.oracle.com/cd/E23824_01/html/819-0690/graphics/ul_bullet.gif);">
<p style="margin-top: 3px; margin-bottom: 17px;">References
to the sections comprising a group from sections outside
of the group must be made through symbol table entries
with <tt style="font-family: Monaco, Courier, 'Courier
New', monospace; color: rgb(68, 68, 68);">STB_GLOBAL</tt> or <tt
style="font-family: Monaco, Courier, 'Courier New',
monospace; color: rgb(68, 68, 68);">STB_WEAK</tt> binding
and section index<tt style="font-family: Monaco,
Courier, 'Courier New', monospace; color: rgb(68, 68,
68);">SHN_UNDEF</tt>. 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 <tt
style="font-family: Monaco, Courier, 'Courier New',
monospace; color: rgb(68, 68, 68);">STB_LOCAL</tt> binding
for addresses that are contained in the group's
sections, including symbols with type <tt
style="font-family: Monaco, Courier, 'Courier New',
monospace; color: rgb(68, 68, 68);">STT_SECTION</tt>.</p>
</li>
</ul>
<div>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. </div>
</div>
<div><br>
</div>
</div>
</blockquote>
This is nice, and thanks for the pointer.<br>
<br>
<blockquote
cite="mid:AF0C5235-C9B3-4E27-8640-053EE3D7015E@apple.com"
type="cite">
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><b>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!.</b><b><br>
</b></div>
</div>
</blockquote>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</blockquote>
Yeah, yes you are right.<br>
<br>
<blockquote
cite="mid:AF0C5235-C9B3-4E27-8640-053EE3D7015E@apple.com"
type="cite">
<div>
<div>I think the solution:</div>
<div>1) keep the existing canonical form for an atom graph that
Passes process</div>
<div>2) make the ELF Writer smart that when it writes
relocatable object files, to synthesize undefined symbols for
references into group children</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
</div>
</blockquote>
The below steps as in the command line would not work though.<br>
<br>
lld -flavor gnu -target x86_64 group.o --output-filetype=yaml
--noinhibit-exec <br>
<br>
(Input file is processed by the ELF reader, convert the read files
to YAML files, re-read the files from YAML back into atoms)<br>
<br>
As the YAML reader wouldnt synthesize undefined atoms ? Its like a
chicken-egg problem.<br>
<br>
I think the Native writer also would have this same issue, right ?<br>
<br>
Thanks<br>
<br>
Shankar Easwaran<br>
<br>
<pre class="moz-signature" cols="72">--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre>
</body>
</html>