From owner-freebsd-toolchain@FreeBSD.ORG Wed Jul 25 10:06:27 2012 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31F3F106566B for ; Wed, 25 Jul 2012 10:06:27 +0000 (UTC) (envelope-from lubatang@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B52588FC1A for ; Wed, 25 Jul 2012 10:06:26 +0000 (UTC) Received: by weyx56 with SMTP id x56so466168wey.13 for ; Wed, 25 Jul 2012 03:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LG/7rHEsnPbyTNmQB86ZiNAEDkA1OeNJ4dS5xmyXFPI=; b=caMqpRPfpskbfv8aln2sIky5J5m/zI9jFEFCT8iH6H0rV/ZYrHFzSWD99+AyDDlOic ddN/6tw6hsmV8bLym8GebWAYHvsuk4hQdur15yUhqFryF9XDnCCnsClwGq0cwnxjhsei jfbJ4SeGosABAntx0ucfdRMVVlVYpZlJRts7mkxIy1fnCdIwqhJkfrhf6zu1IB/e2MFn NbB6HkHKipQQJB8EuiUPZSBEbMrIiOLgXhlERTwRkf36RtN1hTkpg/sL8ANkx3Ft280d vBDAUP6gu2Txgeos/38Z677NpSYnJtf+g4AMbx5mXQYBGC1OU69LSxmP5A8iMIf9LCzx YYzw== MIME-Version: 1.0 Received: by 10.216.182.195 with SMTP id o45mr12482074wem.185.1343210785845; Wed, 25 Jul 2012 03:06:25 -0700 (PDT) Received: by 10.216.48.5 with HTTP; Wed, 25 Jul 2012 03:06:25 -0700 (PDT) In-Reply-To: <0FD17AD0-AD5B-4B06-A966-849699AA4A1D@theravensnest.org> References: <0FD17AD0-AD5B-4B06-A966-849699AA4A1D@theravensnest.org> Date: Wed, 25 Jul 2012 18:06:25 +0800 Message-ID: From: Luba Tang To: David Chisnall Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-toolchain@freebsd.org Subject: Re: MCLinker and llvm-config X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 10:06:27 -0000 2012/7/25 David Chisnall > 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