FYI: gold linker not feasible for Win32 binaries
Jói Sigurðsson
tl;dr: Porting the gold linker to work with COFF objects and PE
binaries is not feasible as it would likely lose most of its performance
benefits.
Longer version: jam@ and I were throwing around ideas last week for
how to increase developer productivity, particularly on Windows where
it kind of sucks right now. One of the ideas that John threw out was
whether we might be able to get the gold linker (that we use for Linux
builds) working on Windows. Just to save anybody else from spending
time looking at this, I wanted to send out this FYI to say that I
spoke with Ian Lance Taylor, the main author of gold, and there are in
fact fundamental assumptions that gold needs to make about its input
format (ELF) to achieve its speed. Ian thought that shoe-horning gold
into being a COFF linker would likely make it just as slow as the gcc
linker (which was originally a COFF linker shoe-horned into linking
ELF files).
On a tangent, Ian mentioned that it used to be the case that the
fastest way to build Windows binaries was to cross-compile them on a
Linux box. Now, I doubt this is still true, and there would likely be
practical issues with it, but just in case: Has anybody tried this
recently?
Cheers,
Jói
Tony Chang
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Nico Weber
> Hi folks,
>
> tl;dr: Porting the gold linker to work with COFF objects and PE
> binaries is not feasible as it would likely lose most of its performance
> benefits.
>
> Longer version: jam@ and I were throwing around ideas last week for
> how to increase developer productivity, particularly on Windows where
> it kind of sucks right now. One of the ideas that John threw out was
> whether we might be able to get the gold linker (that we use for Linux
> builds) working on Windows. Just to save anybody else from spending
> time looking at this, I wanted to send out this FYI to say that I
> spoke with Ian Lance Taylor, the main author of gold, and there are in
> fact fundamental assumptions that gold needs to make about its input
> format (ELF) to achieve its speed.
Out of curiosity, what are the assumptions made by gold?
> Ian thought that shoe-horning gold
> into being a COFF linker would likely make it just as slow as the gcc
> linker (which was originally a COFF linker shoe-horned into linking
> ELF files).
>
> On a tangent, Ian mentioned that it used to be the case that the
> fastest way to build Windows binaries was to cross-compile them on a
> Linux box. Now, I doubt this is still true, and there would likely be
> practical issues with it, but just in case: Has anybody tried this
> recently?
>
> Cheers,
> Jói
>
Jói Sigurðsson
=== cut here ===
The linking process for ELF is inherently different from the linking
process for COFF. It's not a matter of the object files as such; it's
the way linking is done. For ELF you have to build a PLT and a GOT, and
executables wind up being a special case of shared libraries. For COFF
DLLs are very different from executables. gold is much faster than the
GNU linker because the GNU linker is inherently a COFF linker for which
ELF support was shoe-horned in. Trying to shoe-horn a COFF linker into
gold would recreate the same problem which gold was getting away from.
So from my perspective it does not make sense to try to add support for
COFF/PE to gold. Instead, somebody could take the ideas from gold and
write a new linker which supports COFF/PE.
=== cut here ===
Cheers,
Jói