From sacadmin Tue Mar 24 14:36:09 2009 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2OLa9Dv003130; Tue, 24 Mar 2009 14:36:09 -0700 (PDT) Received: (from ab196087@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n2OLa9DQ003126; Tue, 24 Mar 2009 14:36:09 -0700 (PDT) Date: Tue, 24 Mar 2009 14:36:09 -0700 (PDT) From: Ali Bahrami Message-Id: <200903242136.n2OLa9DQ003126@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: ELF objects to set OSABI / elfdump -O option [PSARC/2009/196 Self Review] Status: RO Content-Length: 577 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ELF objects to set OSABI / elfdump -O option 1.2. Name of Document Author/Supplier: Author: Ali Bahrami 1.3 Date of This Document: 24 March, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: on 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From Ali.Bahrami@sun.com Tue Mar 24 14:43:30 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2OLhU7G003613 for ; Tue, 24 Mar 2009 14:43:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n2OLhOp6005632 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 25 Mar 2009 05:43:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH100A095OEB800@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Mar 2009 14:43:26 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH10080Q5OD7C30@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Mar 2009 14:43:25 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2OLhPtD004284 for ; Tue, 24 Mar 2009 21:43:25 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH100K004EIZJ00@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Mar 2009 15:43:25 -0600 (MDT) Received: from [172.20.25.67] ([unknown] [172.20.25.67]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH100FZ65O2YF40@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Mar 2009 15:43:14 -0600 (MDT) Date: Tue, 24 Mar 2009 16:41:08 -0600 From: Ali Bahrami Subject: PSARC 2009/196 ELF objects to set OSABI / elfdump -O option Sender: Ali.Bahrami@sun.com To: psarc-ext@sun.com Message-id: <49C96184.9010506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20090223) Status: RO Content-Length: 8587 I am sponsoring the following self-reviewed case for myself. It makes the following user visible changes: - Solaris ELF objects will henceforth set the e_ident[EI_OSABI] field of the ELF header to ELFOSABI_SOLARIS, instead of the historical value of ELFOSABI_NONE. - elfdump will get a new -O option to allow the user to specify the ELF operating system ABI to use when interpreting the file. For reasons discussed in detail below, the EI_OSABI field of the ELF header is not used by the link-editor, runtime linker, or operating system kernel to affect how it is used by the system. As such, tagging our object as ELFOSABI_SOLARIS is purely documentation, of value to tools such elfdump that are used to examine them, and for compliance with the ELF standard. This change will not alter the runtime behavior of the operating system. ----- Release Binding: Patch/Micro ELF OSABI tagging Committed elfdump -O option Committed ----------------------------------------------------------------------------- The longevity of the ELF standard is largely due to the fact that it was designed to be extended. Operating systems are able to add new features in a controlled and backward compatible manner. However, the original version of the ELF standard, as designed by AT&T, and implemented in Solaris 2.0, did not tackle the question of how different operating systems can do this without suffering from namespace collisions with each other. A few years later, representatives from the various Unix vendors gathered to work out these details (Mike Walker represented Sun). The numeric ranges of ELF constants (representing program header types, section types, and so forth) were partitioned into three separate ranges: Generic: Core ELF features, common to all ELF implementations OS: Operating system specific features, unique to each operating system (at least at first --- good ideas often cross pollinate). This is called the Operating System ABI (OSABI). The OSABI of a given object is recorded in the EI_OSABI field of the ELF header e_ident array --- a byte array of 16 characters that is found at offset 0 of the file. (The ELF magic number is found in e_ident[0:3]). Platform: Hardware specific features. The platform ABI for a given ELF object is identified by the e_machine field of the ELF header. These specifics are defined by the platform ABI. The e_machine field already existed, but the gABI group needed to create a place to record the OSABI. The original ELF specification had defined the ELF e_ident[] array to have 16 bytes, but only the first 7 (indexes 0-6) were used. The remaining 9 bytes were always set to 0. The gABI group decided to use two of these bytes: #define EI_OSABI 7 /* Operating system/ABI identification */ #define EI_ABIVERSION 8 /* ABI version */ Given a self identifying object (via e_ident[EI_OSABI]), and a specific range for OS extensions, different ELF based operating systems are free to evolve, in theory without conflict. Unfortunately for this theory, the OSABI addition to ELF was not an original feature, but one that was added later. All operating systems that existed prior to that change had existing objects in the field with e_ident[EI_OSABI] set to 0 (ELFOSABI_NONE). The ELF standard says that ELFOSABI_NONE objects only use the generic part of the ELF standard. However, for backward compatibility with their own objects, the OS vendors have always applied a somewhat different interpretation. The real world definition of an ELFOSABI_NONE object is that it is a native object that doesn't self identify itself --- all OSABI features are supported, and will work if used. Given the fact that ELFOSABI_NONE in the real world means "native" and not "generic", OS vendors did not move to set the EI_OSABI for their objects. Solaris and Linux both still set this field to ELFOSABI_NONE, even though it is a rare object for either system that does not use an operating system specific ELF feature. This mostly works: - People know that a given object is for a given system because they built it for that system. In a heterogeneous networked environment, things can sometimes get confused, but normally there's little issue. - The ELF community has tried very hard to give their extensions unique non-colliding values. For example, when Linux added symbol versioning, they did it in a manner compatible with Solaris, using the same numeric ELF values to represent the same items. Similarly, we try to track their changes. However, as with any "best effort" solution, there are issues: - I have recently discovered that best efforts notwithstanding, the Solaris and Linux systems have diverged incompatibly: Value Solaris Linux ---------------------------------------------------------------- 0x6ffffff5 SHT_SUNW_cap SHT_GNU_ATTRIBUTES 0x6ffffff6 SHT_SUNW_SIGNATURE SHT_GNU_HASH 0x6ffffff7 SHT_SUNW_ANNOTATE SHT_GNU_LIBLIST 0x6ffffff8 SHT_SUNW_DEBUGSTR SHT_CHECKSUM - When tools like elfdump try to display a non-Solaris object, they will use Solaris names for the items. This looks strange when the names in question represent the same concept. It is simply wrong when they don't. Consider this elfdump output from an Ubuntu Linux executable: Section Header[4]: sh_name: .gnu.hash sh_addr: 0x400320 sh_flags: [ SHF_ALLOC ] sh_size: 0x40 sh_type: [ SHT_SUNW_SIGNATURE ] sh_offset: 0x320 sh_entsize: 0 sh_link: 5 sh_info: 0 sh_addralign: 0x8 It has been apparent for some time that we should be marking our objects as ELFOSABI_SOLARIS. The divergence between Solaris and Linux underscores the fact that even when there is no conflict, there is no reason not to properly identify our objects. This must be a "documentation only" change: Although we will tag our objects as ELFOSABI_SOLARIS, the link-editor, runtime linker, and OS kernel will never be free of the requirement that ELFOSABI_NONE objects must be treated as ELFOSABI_SOLARIS. There is therefore no reason for any of these components to read e_ident[EI_OSABI], or alter their behavior based on its value. ----- The elfdump program has been modified to take the OSABI of the objects it displays into account. When an object identifies as non-Solaris OSABI, elfdump will display the proper strings for that OSABI if it knows them. For example, it will display a Linux versym section type as 'SHT_GNU_versym' instead of 'SHT_SUNW_versym'. If it does not have knowledge of the specified OSABI, it will present such information in numeric form, rather than mapping to Solaris names inappropriately. This ability will enhance elfdump's value when we examine non-Solaris objects (something linker developers do regularly). Since most ELF objects do not properly identify their OSABI, elfdump will receive a new command line option, '-O osabi', allowing the user to tell it which OSABI to apply. The elfdump(1) manpage will document this feature as follows: OPTIONS The following options are supported: ... -O osabi Specifies the Operating System ABI to apply when interpreting the object. osabi can be the name or value of any of the ELFOSABI_ constants found in . For convenience, the ELFOSABI_ prefix may be omitted from these names. If -O is not specified, and the object does not specify an OSABI in the ELF header, the Solaris ABI will be used. Two osabi values are fully supported: 'solaris' is the native OSABI of the Solaris operating system. 'none' is a fully generic ELF ABI --- all values outside the generic range are displayed numerically. Support for other OSABIs may be incomplete or missing. In all cases, elfdump will display items for which strings are unavailable in numeric form.