MCLinker and llvm-config

[Luba Tang]

2012/7/25 David Chisnall <theraven at theravensnest.org>

> On 25 Jul 2012, at 10:22, Luba Tang wrote:
>
> > Let me explain the status of MCLinker.
> > MCLinker now is one of the standard system linkers in Android system.
> > https://android.googlesource.com/platform/frameworks/compile/mclinker
>
> It looks like MCLinker has made a lot of progress since I last checked.
>
> > Since there are many practical issues in ELF system (some of them are
> > undocumented :'( ), I think MCLinker could be said as a linker who is
> > robust enough to handle with wrapped symbols, segments, .group section,
> > exception, DWRAF, and many many ELF unique features. :)
>
> Indeed.  How do you plan on integrating modern features like LTO into
> MCLinker?  Can you deal with an atom-based model for efficient code
> locality?
>

We will introduce a new linking algorithm, we call it "fragment-based
model". Atom-based model is one special case (finest) of "fragment-based
model". This help MCLinker find the best trade-off between linking time and
output quality. The trade-off is important for modern virtual machines.


> > In our plan, we will get rid of LLVM in this September. At that time,
> > MCLinker wil be able to handle archives, and has some basic support for
> > link script.
>
> What does 'get rid of LLVM' mean in this context?
>

Since some friends have helped us to change llvm/Support/ELF.h, the next
step is to get rid of the data structures in MC layer. Thanks for LLVM
community's work, LLVM 3.1 paves a road to change every components we want.
We do not need some straightforward patches for LLVM.


>
> > We have promised BSD systems have higher priority than Linux systems, and
> > we will keep our promise.
>
> That's also great.  The FreeBSD Foundation has some funding set aside for
> linker work, but currently nothing concrete to spend it on, so I'd strongly
> invite people to submit project proposals in this area.
>
> > BTW, I think llvm-config is necessary for every LLVM-based project. If it
> > will not be in BSD system, I think we can negotiate an approach to get
> rid
> > of it.
> > Just like what Android did.
>
> I think the rationale for not having it in the base system is sensible: we
> don't want things from outside the base system to link against the LLVM
> from the base system.  When other things are imported, we will most likely
> replace their own build system (as we do with LLVM itself) and so can hard
> code the location of the LLVM that they link against.
>
> David