[LLVMdev] LLD improvement plan

[Eric Christopher]

On Mon, May 4, 2015 at 3:08 PM Chris Lattner <clattner at apple.com> wrote:

> On May 4, 2015, at 1:16 PM, Joerg Sonnenberger <joerg at britannica.bec.de>
> wrote:
> > It has been said in this thread before, but I fail to see how the atom
> > model is an actual improvement over the fine grained section model. It
> > seems to be artifically restricted for no good reasons.
>
> Sections come with a huge amount of bloat and overhead that atoms do not.
>
>
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.

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. :)

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.


> >> Lets stop thinking about lld as one linker, and instead think of it is
> >> two different ones.  We’ll build a Camp B linker which is the best of
> >> breed section based linker.  It will support linker scripts and do
> >> everything better than any existing section based linker.  The first
> >> step of this is to do what Rui proposes and rip atoms out of the model.
> >
> > This is another item that has been irritating me. While it is a very
> > laudable goal to not depend on linker scripts for the common case, not
> > having the functionality of fine grained output control is certainly a
> > problem. They are crucial for embedded developers and also at least
> > significant for anything near a system kernel.
>
> 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?
>

Linker scripts are worse than everything - except for the alternatives that
we know about. Any particular suggestions here?

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150504/9896dd99/attachment.html>