[lld] r190608 - [lld][LayoutPass] Order the atoms that are in the same chain

[Rui Ueyama]

On Fri, Sep 13, 2013 at 4:01 PM, Shankar Easwaran
<shankare at codeaurora.org>wrote:

> On 9/13/2013 5:47 PM, Rui Ueyama wrote:
>
>> This patch seems to break IdataPass in COFF writer. The COFF writer
>> creates
>> atoms for DLL import table in the pass. Because the atoms created in the
>> pass do not really belong to any input file, the linker uses MutableFile
>> representing the linking result as a dummy value of the file for the
>> atoms.
>> It did work until this patch.
>>
> The patch solves the problem in many ways. Atoms only in their chain are
> ordered, which is what we want to do.
>
>
>  The MutableFile did not have input ordinal value, so it now fails with the
>> assertion at include/lld/Core/File.h:72 checking _ordinal != UINT64_MAX in
>> the layout pass.
>>
>> I think there are many ways to fix this. One way would be to create
>> another
>> dummy input file and use it for the atoms created by the IdataPass. It
>> should work, but I don't think that's a good way because the dummy file is
>> really dummy and does not do anything useful. It feels like the
>> restriction
>> that atoms must have associated input files is too strict.
>>
> We use SimpleFile at all places.


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.

 So I'd want to make _file field optional for the atom. What do you guys
>> think?
>>
> I dont think we do this.
>

Can you elaborate?


> 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/20130913/96858630/attachment.html>