[LLVMdev] LLD improvement plan

Joerg Sonnenberger joerg at britannica.bec.de
Mon May 4 16:18:32 PDT 2015


On Mon, May 04, 2015 at 03:05:47PM -0700, Chris Lattner 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.

I don't buy that as far as the internal representation is concerned.
On-disk format as Eric said is a somewhat different question.

> >> 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?

I haven't seen the better alternative yet. It is hard to reason about
vaporware. I'm not particulary attached to linker scripts, they are
certainly a horrible language. But the lack of support is certainly a
show stopper for those areas where the functionality is needed.
How is a linker supporting at least a major part of that functionality
going to be different from a linker that accepts linker scripts as
input?

Joerg




More information about the llvm-dev mailing list