<div dir="ltr">On Fri, Sep 13, 2013 at 4:01 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 9/13/2013 5:47 PM, Rui Ueyama wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
This patch seems to break IdataPass in COFF writer. The COFF writer creates<br>
atoms for DLL import table in the pass. Because the atoms created in the<br>
pass do not really belong to any input file, the linker uses MutableFile<br>
representing the linking result as a dummy value of the file for the atoms.<br>
It did work until this patch.<br>
</blockquote></div>
The patch solves the problem in many ways. Atoms only in their chain are ordered, which is what we want to do.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The MutableFile did not have input ordinal value, so it now fails with the<br>
assertion at include/lld/Core/File.h:72 checking _ordinal != UINT64_MAX in<br>
the layout pass.<br>
<br>
I think there are many ways to fix this. One way would be to create another<br>
dummy input file and use it for the atoms created by the IdataPass. It<br>
should work, but I don't think that's a good way because the dummy file is<br>
really dummy and does not do anything useful. It feels like the restriction<br>
that atoms must have associated input files is too strict.<br>
</blockquote></div>
We use SimpleFile at all places.</blockquote><div><br></div><div>I know we are using SimpleFile for GOT/PLT atoms, for example, and I doubt that's a good design. These atoms are not read from any files but produced by the linker after the core liking is done so semantically they don't belong to any file. A SimpleFile is used only as a dummy value because it's mandatory. We might be able to simplify the thing by making an optional thing optional.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So I'd want to make _file field optional for the atom. What do you guys<br>
think?<br>
</blockquote></div>
I dont think we do this.<br></blockquote><div><br></div><div>Can you elaborate?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Thanks<span class=""><font color="#888888"><br>
<br>
Shankar Easwaran<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</font></span></blockquote></div><br></div></div>