Date: Wed, 25 Jul 2012 18:06:25 +0800 From: Luba Tang <lubatang@gmail.com> To: David Chisnall <theraven@theravensnest.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: MCLinker and llvm-config Message-ID: <CAMW0cxnX8fsj53Y%2B%2BUfP6fqPRsNQKPpwEZjCvvvJaDGOpHW4yA@mail.gmail.com> In-Reply-To: <0FD17AD0-AD5B-4B06-A966-849699AA4A1D@theravensnest.org> References: <CAMW0cx=hw=OaJVOHWQKkbgzJq1XNbMn5KjDYKEVkp-tffFqNFw@mail.gmail.com> <0FD17AD0-AD5B-4B06-A966-849699AA4A1D@theravensnest.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/7/25 David Chisnall <theraven@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMW0cxnX8fsj53Y%2B%2BUfP6fqPRsNQKPpwEZjCvvvJaDGOpHW4yA>