From Rod.Evans@sun.com Wed Sep 26 11:32:12 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8QIWBoa020878 for ; Wed, 26 Sep 2007 11:32:11 -0700 (PDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l8QIT8mN499867 for ; Wed, 26 Sep 2007 11:29:09 -0700 (PDT) Message-ID: <46FAA43C.2040203@sun.com> Date: Wed, 26 Sep 2007 11:26:04 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems Inc. User-Agent: Thunderbird 2.0.0.4 (X11/20070703) MIME-Version: 1.0 To: psarc-ext@sac.sfbay.sun.com Subject: 2007/559: new symbol visibilities - EXPORTED, SINGLETON, and ELIMINATE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2600 I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. ------------------------------------------------------------------------ 6602451 documents the requirements for some new symbol visibilities. These visibilities are defined as ELF_ST_VISIBILITY() values within a symbols "st_other" field. As this is a "public" ELF field, the proposal was passed around several ELF vendors. See: http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc1566616 The proposal started with our requirement to add STV_SINGLETON and STV_ELIMINATE. However, we found that SCO had already added to this public arena with STV_EXPORTED. We therefore intend to add three new visibilities: STV_EXPORTED Indicates that a symbol is to remain global and can not be demoted or eliminated by any other linking technique. STV_SINGLETON Indicates that only once instance of the symbol can be bound to by any reference. This is a long standing C++ requirement that has relied upon interposition (but has been broken by several linking techniques, such as symbol scoping, -Bsymbolic and direct-binding). STV_ELIMINATE Indicates that a symbol should be eliminated from any symbol tables. Required by DTrace. ------------------------------------------------------------------------ This fast track also adds a new observability option to lari(1): User Commands lari(1) SYNOPSIS lari [-bCDsVv] [-a | -i | -o] file | directory... | lari [-CDosv] [-m [-d mapdir]] file | .... -V | Appends interesting symbol visibilities. Symbols that | are defined as singleton or are defined protected are | identified with this option. | ------------------------------------------------------------------------ Public Header additions: usr/src/uts/common/sys/elf.h #define STV_EXPORTED 4 #define STV_SINGLETON 5 #define STV_ELIMINATE 6 usr/src/uts/common/sys/link.h #define DF_1_SINGLETON 0x02000000 ------------------------------------------------------------------------ Release Binding: Patch/Micro sys/elf.h additions Commited sys/link.h additions Commited lari(1) -V Commited -- Rod. From Rod.Evans@sun.com Tue Oct 2 09:57:36 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l92GvaUa014304 for ; Tue, 2 Oct 2007 09:57:36 -0700 (PDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l92GsStC780150 for ; Tue, 2 Oct 2007 09:54:28 -0700 (PDT) Message-ID: <47027709.2090705@sun.com> Date: Tue, 02 Oct 2007 09:51:21 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems Inc. User-Agent: Thunderbird 2.0.0.4 (X11/20070703) MIME-Version: 1.0 To: psarc-ext@sac.sfbay.sun.com Subject: Re: 2007/559: new symbol visibilities - EXPORTED, SINGLETON, and ELIMINATE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 396 Just for the record, there's a cut-and-paste error: > As this is a "public" ELF field, the proposal was passed around several > > ELF vendors. See: > > > > http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc1566616 The link should be: http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc15666164 Bug report 660245 has the correct link. -- Rod. From Nicolas.Williams@sun.com Tue Oct 2 10:16:40 2007 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l92HGewQ015550 for ; Tue, 2 Oct 2007 10:16:40 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l92HDVFY017862; Tue, 2 Oct 2007 12:13:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l92HDV0P017861; Tue, 2 Oct 2007 12:13:31 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 2 Oct 2007 12:13:31 -0500 From: Nicolas Williams To: Rod Evans Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: 2007/559: new symbol visibilities - EXPORTED, SINGLETON, and ELIMINATE Message-ID: <20071002171331.GD11376@Sun.COM> References: <47027709.2090705@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47027709.2090705@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1179 On Tue, Oct 02, 2007 at 09:51:21AM -0700, Rod Evans wrote: > Just for the record, there's a cut-and-paste error: > > > As this is a "public" ELF field, the proposal was passed around several > > > ELF vendors. See: > > > > > > > http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc1566616 > > The link should be: > > http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc15666164 > > Bug report 660245 has the correct link. A few questions: Can one interpose on singleton symbols using LD_PRELOAD? I assume yes, or at most that the interposers in the pre-loaded object must be labelled singleton as well. Will dlsym(RTLD_NEXT, ) return the next symbol? Or the one bound symbol (it is a singleton, after all)? If multiple objects define the same singleton symbol, will dlsym() called with a handle for each of those objects resolve the same symbol to the first definition, or to each object's version? Presumably libraries designed so that multiple versions can be present in one process (I think that's feasible, with some constraints) must not use singleton symbols. Nico -- From Rod.Evans@sun.com Tue Oct 2 13:09:16 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l92K9GRO023961 for ; Tue, 2 Oct 2007 13:09:16 -0700 (PDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l92K67bq821681; Tue, 2 Oct 2007 13:06:07 -0700 (PDT) Message-ID: <4702A3F4.2030706@sun.com> Date: Tue, 02 Oct 2007 13:03:00 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems Inc. User-Agent: Thunderbird 2.0.0.4 (X11/20070703) MIME-Version: 1.0 To: Nicolas Williams CC: psarc-ext@sac.sfbay.sun.com Subject: Re: 2007/559: new symbol visibilities - EXPORTED, SINGLETON, and ELIMINATE References: <47027709.2090705@sun.com> <20071002171331.GD11376@Sun.COM> In-Reply-To: <20071002171331.GD11376@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1030 Nicolas Williams wrote: > A few questions: > > Can one interpose on singleton symbols using LD_PRELOAD? I assume > yes, or at most that the interposers in the pre-loaded object must be > labelled singleton as well. An interposer can win, it still provides the *first* symbol. > Will dlsym(RTLD_NEXT, ) return the next symbol? Or > the one bound symbol (it is a singleton, after all)? > > If multiple objects define the same singleton symbol, will dlsym() > called with a handle for each of those objects resolve the same > symbol to the first definition, or to each object's version? It doesn't matter how a symbol is located, via relocation of via dlsym() (or what flag you use in dlsym()), the effect should be that same, in that all references get bound to one definition. > Presumably libraries designed so that multiple versions can be > present in one process (I think that's feasible, with some > constraints) must not use singleton symbols. Correct. -- Rod.