From owner-freebsd-toolchain@FreeBSD.ORG Sun Jul 29 13:20:53 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 23EDE106566B; Sun, 29 Jul 2012 13:20:53 +0000 (UTC) (envelope-from lubatang@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5920D8FC15; Sun, 29 Jul 2012 13:20:52 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3903550wgb.31 for ; Sun, 29 Jul 2012 06:20:51 -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=qpg8wOxIuYu8z3GdWIGCDwU4GBLVegy/138CXaI97yc=; b=LZtmeArvCVmCIb05WuOzCqUA0a8gkbD7iW0rLN3xldD7kRyzFE8X/sfdnEwM5QLDpW l+gdGBwFxRGoNo36uRrCVzgEuJSVOxHIaIxBwedvEsEUuK4LytayY446l6WXtE6Rvry/ aMKeydKfvjSg8tNIq3Z9qYUp0FptLQgrp1dXa/hEvzDGAepHaMW2Q1WDoqBJg6/8+KF6 hU0/89TVaNn/tTTtZYJXbN++hhLxdJ4DUpwJIo+ujop1rhqS3JvHfHRFaAJr0Tylu5Y1 WQU6v2rbEemIPbUkn3kKCgXx+RZxUYj4XCYtMzlZFMQrvxbTkE0qgET23MV44yzsGZjO Aicg== MIME-Version: 1.0 Received: by 10.180.97.33 with SMTP id dx1mr19295652wib.18.1343568051389; Sun, 29 Jul 2012 06:20:51 -0700 (PDT) Received: by 10.216.48.5 with HTTP; Sun, 29 Jul 2012 06:20:51 -0700 (PDT) In-Reply-To: References: <1343484950.37325.YahooMailNeo@web113506.mail.gq1.yahoo.com> Date: Sun, 29 Jul 2012 21:20:51 +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: Pedro Giffuni , "freebsd-toolchain@freebsd.org" Subject: Re: BSD ld (was 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: Sun, 29 Jul 2012 13:20:53 -0000 > The linker's ELF generation support is similarly overlapping with that of > the compiler, and I would much rather that we have a single implementation > in the base system than two. > There are some thing I can share. One years ago, when we were brainstoming the idea of MCLinker, we also discussed similar idea - "Can we leverage ELF reading/generation part of LLVM?". Unfortunately, we found the answer is negative when we were in the design stage. The reasons are: 1. For performance reasons, linkers does not read the whole input files. Linkers read a piece of input files on demand. Not only MCLinker, but also Google gold linker, we do not read the whole object files at once. We read a piece of object files, interpret them, and then drop them away immediately. When we need the same piece of object files, we read it again. This is because the scale of the numbers of relocations and symbols are usually 1~100 million, it's huge, but linkers use only a few of them in one process. For smaller memory footprint, linkers do not keep them in the memory, linkers read them from input files on demand. Takes Google gold for example, she reads relocations on-demand. Everywhen she needs a relocation, she reads the input file again and interpret relocation entries. This approach is very efficient. Because linkers usually mmap input files on pages, the file I/O is small. Google gold saves huge amount of memory at the small cost of re-interpreting time. However, the other tools (objdump, nm, and so on) don't need handle with such huge scale problem. They usually simply keeps everything in memory. That is one reason why linkers should have their own special readers and do not reuse the readers of the other tools. 2. Like compilers, linkers also have intermeidate representation (IR). Every linker needs a customized reader to build IR. MCLinker bases on fragment-based model, GNU ld bases on BFD model, ld64 bases on atom-based model,... Different model has its own unique strength and ususally favor certain file format. MCLinker and Google gold favor ELF, ld64 favors MachO, and GNU ld favors COFF+ (I guess, may not right). All linker IRs are a kind of directive acyclic graph (DAG). The main differences of these IRs are the direction of the edges. The readers of the other tools have no idea about linker IR, and this makes reusing is a slim chance. Best regards, Luba David_______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to " > freebsd-toolchain-unsubscribe@freebsd.org" >