<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 11, 2015 at 11:21 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, May 11, 2015 at 11:13 AM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If you attach two ore more symbols along with offsets to a chunk of data, it would be a pretty similar to a section. That means that if you want to do something on the atom model, now you have to treat the atoms like sections. </div></blockquote></span><div><br>What do you lose/pay by having to treat the atoms like sections?<br></div></div></div></div></blockquote><div><br></div><div>I can think of a few, maybe more.</div><div><br></div><div>An atom model with multiple names is not as simple as before.</div><div><br></div><div>We still need to read all relocation tables to complete a graph as they form edges, even for duplicate COMDAT sections.</div><div><br></div><div>It still can't model some section-linker features, such as "select largest" COMDAT sections, because the new atom is still different from the section. (This is not an issue if we really treat atoms like sections, but that means in turn we would be going to create a Mach-O linker based on the section model.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I looks like a bad mix of the two.</div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, May 11, 2015 at 10:56 AM, James Y Knight <span dir="ltr"><<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>></span> wrote:<br></span><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nobody in this long thread appears to have yet explained why it's a bad idea to allow atomic fragments of code/data (whatever you want to call them: atoms, sections, who cares) to have more than one global symbol attached to them in LLD's internal representation.<div><br></div><div>That seems like it'd provide the flexibility needed for ELF without hurting MachO. If that change'd allow you to avoid splitting the linker into two-codebases-in-one, isn't that preferable?</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 7, 2015 at 9:38 AM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, May 06, 2015 at 09:28:54PM -0500, Shankar Easwaran wrote:<br>
> The atom model allowed lld to have a single intermediate<br>
> representation for all the formats ELF/COFF/Mach-O. The native model<br>
> allowed the intermediate representation to be serialized to disk<br>
> too. If the intermediate representations data structures are made<br>
> available to scripting languages most of all linker script script<br>
> layout can be implemented by the end user. A new language also can<br>
> be developed as most of the users need it and it can work on this<br>
> intermediate representation.<br>
><br>
> The atom model also simplified a lot of usecases like garbage<br>
> collection and having the resolve to deal just with atoms. The<br>
> section model would sound simple from the outside but it it has its<br>
> own challenges like separating the symbol information from section<br>
> information.<br>
<br>
</span>I'm sorry, but I don't get why any of this requires an atom based<br>
representation. Saying that a single intermediate representation for<br>
ELF/COFF on one hand and Mach-O on the other is ironic given the already<br>
mentioned hacks on various layers. Garbage collection doesn't become<br>
more expensive when attaching more than one symbol to each code/data<br>
fragment. Symbol resolution doesn't change when attaching more than one<br>
symbol to each code/data fragment. The list goes on. The single natural<br>
advantage is that you can use a single pointer to the canonical symbol<br>
from a code/data fragment and don't have to use a list/array. Given the<br>
necessary and expensive hacks for splitting sections into (pseudo)<br>
atoms, that doesn't feel like a win. So once again, what actual<br>
advantages for ELF or COFF have been created by the atom model? Mach-O<br>
hardly counts as it doesn't allow the flexibility of the section model<br>
as has been discussed before.<br>
<span><font color="#888888"><br>
Joerg<br>
</font></span><div><div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>