Someone smarter than I: does this case help us at all at this point?
---------- Forwarded message ---------- From: Ali Bahrami <[email protected]> Date: Wed, Mar 5, 2008 at 7:40 PM Subject: PSARC/2008/179 cross link-editor To: PSARC-ext at sun.com I am sponsoring the following self-reviewed case for myself. I believe it qualifies for self review: The changes have limited scope, are similar to existing features, and preserve full backward compatibility. Release Binding: Patch/Micro '-z target=' ld option: Committed DT_SUNW_LDMACH dynamic tag Committed --------------------------------------------------------------------------- Overview -------- The integration of 6671255 link-editor should support cross linking will extend the Solaris link-editor from being a purely native linker, to a cross linker. This means that a linker running on any Solaris host will be able to link objects for any other supported target system. We see two benefits: - Simplify porting of OpenSolaris to new architectures. The Solaris code makes heavy use of the unique features supported by Solaris link-editor, many of which were developed for just that purpose. Ports of OpenSolaris usually attempt to bootstrap using the GNU ld, which already supports cross linking, but which does not support all the Solaris features we use. The ability to add a new target to the Solaris linker using a non-native host, and then to use that linker to bootstrap the rest of the system is a significant shortcut. - Allows the use of fast/cheap commodity desktop systems to build objects for other systems, be they large expensive systems, or small embedded devices. New ld command option: -z target=XXX ------------------------------------ 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 extend this mechanism 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. Supported target types will be 'sparc', and 'x86'. New ELF Dynamic Section tag: DT_SUNW_LDMACH ------------------------------------------- A cross link-editor has to contend with byte order and alignment issues not encountered by a native link-editor. Errors in the code that handles this can lie latent in a native linker and only cause problems when the linker host and target have different requirements. When debugging linker issues, it will be important to be able to reliably determine the machine type of the linker that produced the object. The link-editor will tag every dynamic object it produces with a DT_SUNW_LDMACH dynamic section entry. DT_SUNW_LDMACH is an integer containing the EM_* ELF machine type code for the linker that produced the object. This information is not used by the runtime linker, and exists purely as documentation. It is easily displayed via dump, elfdump, or elfedit. For example, given a sparc a.out binary built using the Solaris X86 cross linker: % elfdump a.out | grep EM_ e_machine: EM_SPARC32PLUS e_version: EV_CURRENT [27] SUNW_LDMACH 0x3 EM_386 Even in a native linking situation, the presence of SUNW_LDMACH can be informative, as it allows us to determine whether the 32-bit or 64-bit version of the link-editor was employed. _______________________________________________ opensolaris-arc mailing list opensolaris-arc at opensolaris.org -- PGP Public Key 0x437AF1A1 Available on hkp://pgp.mit.edu
