Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Jul 2012 10:01:53 +0100
From:      David Chisnall <theraven@freebsd.org>
To:        Pedro Giffuni <pfg@freebsd.org>
Cc:        "freebsd-toolchain@freebsd.org" <freebsd-toolchain@freebsd.org>
Subject:   Re: BSD ld (was Re: MCLinker and llvm-config)
Message-ID:  <F3939D80-0026-4315-B1B7-D17065AA5022@freebsd.org>
In-Reply-To: <1343484950.37325.YahooMailNeo@web113506.mail.gq1.yahoo.com>
References:  <1343484950.37325.YahooMailNeo@web113506.mail.gq1.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 28 Jul 2012, at 15:15, Pedro Giffuni wrote:

> The Elftoolchain project has been developing a BSD ld:
>=20
> http://sourceforge.net/apps/trac/elftoolchain/=20
>=20
>=20
> http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/ld=20
>=20
>=20
> I thought that would be the official FreeBSD implementation.

There is not yet any consensus as to which linker will be the =
replacement, nor on whether the replacement in 10.0 will be the one that =
we use long-term.  The requirements for 10.0 are, I believe:

- Actually exists
- Capable of linking base on all tier 1 platforms (which, in 10.0, =
hopefully will include ARMv7)
- Cross-linking support (ideally without having to build multiple =
versions of the linker binary)
- Permissive license

The longer-term requirements are:

- Good integration with the rest of the toolchain, including
    - LTO support
    - Code reuse
- Ability to link all (or, at least initially, most) ports
- Easy to add support for new architectures
- Active upstream community
- Good performance (both in terms of linkage speed and generated =
binaries)

Unfortunately, in general the ELF toolchain project is duplicating a lot =
of the work done in LLVM and not in an especially reusable way.  For =
example, when you add a compiler back end in LLVM you get a disassembler =
for free and an assembler with a small amount of effort, which means =
that an LLVM-based objdump and as will share code with the compiler, =
meaning better testing and few places for bugs to hide.  It also means =
that when we get compiler support for a new platform from the compiler, =
we get those tools for free.  For example, llvm-objdump can disassemble =
the CHERI variant of the MIPS instruction set correctly (including =
identifying relocation types), but no other objdump can, and this did =
not require any objdump-specific code to be written. =20

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.=20

David=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F3939D80-0026-4315-B1B7-D17065AA5022>