2012/7/25 David Chisnall <thera...@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 _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
