ld Is Now A Cross Link-Editor

Ali Bahrami — Wednesday March 19, 2008

Until yesterday, ld, the Solaris link-editor, was a native linker. This means that it was only able to link objects for the same machine that the linker was running on. To link sparc objects required the use of of a sparc machine, and x86 objects required an x86 system.

With the integration of

6671255 link-editor should support cross linking

The user interface to this new capability is a simple extension of ld's traditional behavior. Traditionally, ld establishes the class (whether the object is 32 or 64-bit) of the object being generated by examining the first ELF object processed from the command line. In the case where an object is being built solely from an archive library or a mapfile, the -64 command line option is available to explicitly override this default. We have extended this to also determine the machine type of the object to produce:

• The class and machine type of the resulting object default to those of the first ELF object processed from the command line.

• The new '-z target=' command line option can be used to explicitly specify the machine type.

Of course, it's a rare program that doesn't link against at least one system library. You're going to need libc, if nothing else. To do a successful cross-link, you'll need to have an image of the root filesystem for a system of the target type. There are many ways to do this. For testing purposes, I used a sparc and x86 system, using NFS to allow each system to see the root filesystem of the other.

Even though we now have a cross link-editor, we expect that the vast majority of links will be native, for the machine running the linker. We decided to pursue cross linking anyway, for two reasons:

1. To lower the bar for OpenSolaris ports: People have had some success using the GNU ld to port OpenSolaris, but it is difficult to get very far that way. The code in Solaris depends on link-editor features that are specific to the Solaris ld, so using GNU ld involves a fair amount of hacking around these things to make progress, and the farther up the stack you go from the kernel to userland, the harder it gets. We hope that providing a better framework for adding targets to the Solaris ld will help such efforts. It should now be possible (though still not trivial!) to add support for a new target to the Solaris linker running on sparc or x86, and then use the resulting system to cross-build for the new platform.

2. To allow the use of fast/cheap commodity desktop systems to build objects for other systems, be they large expensive systems, or small embedded devices.

A cross link-editor is a significant step, but is of little use unless you also have a cross-compiler and assembler. The GNU gcc compiler can be built as a cross compiler, and that should be very helpful for OpenSolaris ports. However, the Sun Studio compilers are native compilers, so it will still be awhile before I can use my amd64 desktop to build a sparc version of Solaris as part of work at Sun. We've taken a first step. It will be interesting to see what follows.

Comments

UX-admin — Thursday March 20, 2008

I believe that an error was made in the implementation of "-z target=..."

What's the error? It's inconsistent.

-z target=

should be either:

a) sparc

or

b) i86pc (or i386/amd64, if that is more appropriate)

and NOT "x86", as that does not exist on Solaris. Anywhere.

The all-encompassing platform for "x86" and "x64" is i86pc.

Just like it wouldn't make sense to have "-z target=sparcv8plusvis".

Can this please be fixed?
Pretty please with sugar on top.

This bothers me so much, I'm even prepared to put in the work myself, if you'll sponsor me.

Ali Bahrami — Thursday March 20, 2008

I certainly hope this is the worst mistake I've made... :-)

I chose x86 because that is the all-encompassing token used by the C preprocessor. __x86 is defined for either 32 or 64-bits, while __i386 is defined for 32-bits only and __amd64 for 64-bits. So while I see your point with i86pc (the value returned by uname), I'm not really convinced that x86 is a worse choice for this linker option than i86pc.

So my counter arguments are (1) Widely understood term (2) Has compiler affinity, (3) Neither PSARC nor my Solaris savy code reviewers had an issue, (4) The -ztarget option is unlikely to see significant use anyway, as the linker usually figures out the machine from the first object.

If I've failed to convince you, please feel free to email me (I believe you can derive the address based on my name and the usual @Sun.COM) and we'll work it out. Thanks for your interest.

Published Elsewhere

[10] Avoiding LD_LIBRARY_PATH

Blog Index (ali)

[12] Cost Of ELF Symbol Hashing