<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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><div><br>What do you lose/pay by having to treat the atoms like sections?<br> </div><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 class="">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 class="h5"><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">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><br></div></div>