<div dir="ltr"><br><br><div class="gmail_quote">On Mon, May 4, 2015 at 3:08 PM Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On May 4, 2015, at 1:16 PM, Joerg Sonnenberger <<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>> wrote:<br>
> It has been said in this thread before, but I fail to see how the atom<br>
> model is an actual improvement over the fine grained section model. It<br>
> seems to be artifically restricted for no good reasons.<br>
<br>
Sections come with a huge amount of bloat and overhead that atoms do not.<br>
<br></blockquote><div><br></div><div>Caveat: My response isn't in favor of one way over the other, but providing some explanations or trying to frame the trade-offs in a more explicit form.</div><div><br></div><div>Sections come with _some_ size overhead that an atom doesn't because an atom is contained within a section, however, atoms come with a link time cost that sections don't. Trade off. :)</div><div><br></div><div>The atom model is effective for minimizing the size of on disk representation or working around limited object container formats. Being able to just append sections is a trade off for speed of linking versus size of inputs at the moment (which is a tricky trade-off as the speed of linking starts to approach the size of the objects being linked). That said, I don't think any of the current linkers are currently I/O bound here either.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> Lets stop thinking about lld as one linker, and instead think of it is<br>
>> two different ones.  We’ll build a Camp B linker which is the best of<br>
>> breed section based linker.  It will support linker scripts and do<br>
>> everything better than any existing section based linker.  The first<br>
>> step of this is to do what Rui proposes and rip atoms out of the model.<br>
><br>
> This is another item that has been irritating me. While it is a very<br>
> laudable goal to not depend on linker scripts for the common case, not<br>
> having the functionality of fine grained output control is certainly a<br>
> problem. They are crucial for embedded developers and also at least<br>
> significant for anything near a system kernel.<br>
<br>
I’m not saying that the linker should eschew fine grained control, I’m saying it should dump linker scripts (and replace them with something better).  Are you going to argue that linker scripts are great, or that they are what we would end up with if we weren’t driven by backwards compatibility goals?<br></blockquote><div><br></div><div>Linker scripts are worse than everything - except for the alternatives that we know about. Any particular suggestions here?</div><div><br></div><div>-eric </div></div></div>