From sacadmin Wed Jan 20 11:39:50 2010 Received: from chaz.sfbay.sun.com (chaz.SFBay.Sun.COM [129.146.228.120]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0KJdnuC017450; Wed, 20 Jan 2010 11:39:49 -0800 (PST) Received: from chaz.sfbay.sun.com (localhost [127.0.0.1]) by chaz.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0KJdapS001804; Wed, 20 Jan 2010 11:39:36 -0800 (PST) Received: (from rie@localhost) by chaz.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id o0KJdaNV001801; Wed, 20 Jan 2010 11:39:36 -0800 (PST) Date: Wed, 20 Jan 2010 11:39:36 -0800 (PST) From: Rod Evans Message-Id: <201001201939.o0KJdaNV001801@chaz.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Linker-editors: Symbol Capabilities [PSARC/2010/022 FastTrack timeout 01/27/2010] Status: RO Content-Length: 571 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Linker-editors: Symbol Capabilities 1.2. Name of Document Author/Supplier: Author: Rod Evans 1.3 Date of This Document: 20 January, 2010 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: OSNet 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Rod.Evans@sun.com Wed Jan 20 12:12:45 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0KKCjxD018535 for ; Wed, 20 Jan 2010 12:12:45 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0KKCb1k025605 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 20 Jan 2010 12:12:45 -0800 (PST) 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 <0KWK00I0VAT1PY00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 20 Jan 2010 12:12:37 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWK00FCYAT0TA40@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 20 Jan 2010 12:12:36 -0800 (PST) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0KKCaRc103159 for ; Wed, 20 Jan 2010 12:12:36 -0800 (PST) Date: Wed, 20 Jan 2010 12:12:23 -0800 From: Rod Evans Subject: PSARC/2010/022 Linker-editors: Symbol Capabilities To: psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <4B5763A7.4050206@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 13966 I'm sponsoring the following Fact-Track, time out Jan 27th 2010. ------------------------------------------------------------------------------- The link-editors provide a number of means for selecting alternative implementations at runtime. Reserved tokens can be used with runpaths (ie. $PLATFORM), and capabilities can be recorded within dynamic objects (ie. ELF{32|64}_Cap - $HWCAP). On SPARC, the model for using these techniques is through numerous "psr" libraries, provided by a network of symlinked libraries under /platform. This "model" is rather complex, hard to maintain (at least from a packaging point of view), and can, when the optimized functions are not heavily used, actually lead to a runtime overhead because of searching for "psr" candidates. The compiler engineers have also asked for a means of selecting between a family of functions contained within the same dynamic object. Each family member is compiled differently to use various capabilities, where these capabilities can be provided by different systems. To reduce "psr" overhead, and address the compiler requirements, the capabilities that can be recorded within dynamic objects have been extended, and an ELF infrastructure has been created that associates individual symbols with their required capabilities. With this infrastructure, a family of functions, each with different capability requirements, can be contained within a single dynamic object. The runtime linker can use this infrastructure to analyze a capabilities family at runtime, and select the best function to bind to for the underlying system. In other words, we can take the contents of all our libc_psr libraries and put them in one libc.so.1. Then we can then throw away the /platform symlinked psr libraries. The change in the link-editors is being tracked under: 6918143 symbol capabilities ------------------------------------------------------------------------------- Presently, the capabilities that can be defined within an object are derived from the HWCAP aux vector flags (see AV_SPARC in sys/auxv_SPARC.h and AV_386 in sys/auxv_386.h). However, these capabilities are insufficient to represent the present "psr" incantations. The capability tags have been expanded to provide: i. a platform name (one or more can be applied to a capabilities group) ii. a machine hardware name ( " " " " " ") iii. a capabilities identifier name The latter identifier (iii.) does not add to the capabilities definitions, but provides a means of symbolically naming a capabilities group (this comes in to play with the new ld(1) -z symbolcap option ... more later). With these identifiers, we can now, for example, identify a capabilities group that would be applicable for an "opl" system: Symbol Capabilities: index tag value [4] CA_SUNW_ID sun4u-opl [5] CA_SUNW_PLAT SUNW,SPARC-Enterprise or, even more fun, one of the existing hwcap variants (this is "psr" variant that gets loop-back mounted on a "psr" mount point): Symbol Capabilities: index tag value [7] CA_SUNW_ID sun4u-us3-hwcap1 [8] CA_SUNW_PLAT SUNW,A70 [9] CA_SUNW_PLAT SUNW,Netra-210 [10] CA_SUNW_PLAT SUNW,Netra-240 [11] CA_SUNW_PLAT SUNW,Netra-440 [12] CA_SUNW_PLAT SUNW,Netra-CP3010 [13] CA_SUNW_PLAT SUNW,Netra-T12 [14] CA_SUNW_PLAT SUNW,Netra-T4 [15] CA_SUNW_PLAT SUNW,Sun-Blade-1000 [16] CA_SUNW_PLAT SUNW,Sun-Blade-1500 [17] CA_SUNW_PLAT SUNW,Sun-Blade-2500 [18] CA_SUNW_PLAT SUNW,Sun-Fire-15000 [19] CA_SUNW_PLAT SUNW,Sun-Fire-280R [20] CA_SUNW_PLAT SUNW,Sun-Fire-480R [21] CA_SUNW_PLAT SUNW,Sun-Fire-880 [22] CA_SUNW_PLAT SUNW,Sun-Fire-V210 [23] CA_SUNW_PLAT SUNW,Sun-Fire-V215 [24] CA_SUNW_PLAT SUNW,Sun-Fire-V240 [25] CA_SUNW_PLAT SUNW,Sun-Fire-V245 [26] CA_SUNW_PLAT SUNW,Sun-Fire-V250 [27] CA_SUNW_PLAT SUNW,Sun-Fire-V440 [28] CA_SUNW_PLAT SUNW,Sun-Fire-V445 [29] CA_SUNW_PLAT SUNW,Sun-Fire-V490 [30] CA_SUNW_PLAT SUNW,Sun-Fire-V890 [31] CA_SUNW_PLAT SUNW,Sun-Fire [32] CA_SUNW_MACH sun4u The present Elf{32|64}_Cap data structure is captured in a SHT_SUNW_CAP section, .SUNW_cap. This data structure consists of one or more CA_SUNW_* tags, and a terminating CA_SUNW_NULL (0) tag. This data structure, which starts at .SUNW_cap[0] defines the capabilities of the object. This "convention" will remain unchanged. This project allows there to be multiple CA_SUNW_NULL terminated capabilities groups. Again, .SUNW_cap[0] defines the capabilities of the object, but any follow on groups allow for the definition of symbol capabilities. A new SHT_SUNW_capinfo section is provided. This section is an array that parallels the symbol table, and allows individual symbols to be associated with capability groups. elfdump(1)'s existing -H option displays capabilities information, and when symbol capabilities are detected, will display the capabilities and the associate symbols: % elfdump -H /lib/libc.so.1 Capabilities Section: .SUNW_cap Symbol Capabilities: index tag value [1] CA_SUNW_ID sun4u [2] CA_SUNW_MACH sun4u Symbols: index value size type bind oth ver shndx name [1] 0x000f05e0 0x000000bc FUNC LOCL D 0 .text memmove%sun4u [7] 0x000f1aac 0x00001b28 FUNC LOCL D 0 .text memcmp%sun4u [11] 0x000f069c 0x00001280 FUNC LOCL D 0 .text memcpy%sun4u [17] 0x000f1920 0x0000018c FUNC LOCL D 0 .text memset%sun4u Symbol Capabilities: index tag value [4] CA_SUNW_ID sun4u-opl [5] CA_SUNW_PLAT SUNW,SPARC-Enterprise Symbols: index value size type bind oth ver shndx name [2] 0x000f3600 0x00000310 FUNC LOCL D 0 .text memmove%sun4u-opl [8] 0x000f424c 0x00000120 FUNC LOCL D 0 .text memcmp%sun4u-opl [12] 0x000f3940 0x0000076c FUNC LOCL D 0 .text memcpy%sun4u-opl [18] 0x000f40c0 0x0000018c FUNC LOCL D 0 .text memset%sun4u-opl .... Each capabilities symbol is local. This prevents direct access to these symbols from any external reference. External references are directed to a global lead symbol, i.e., memmove(), memcpy(), etc. These lead symbols provide the generic instance of the function, one that is not compiled to require any capabilities. A new SHT_SUNW_capchain section is provided within dynamic objects. This structure contains one of more collections of capabilities families, each lead by the global lead symbol. When the runtime linker binds to a capabilities lead symbol, i.e., memcpy(), the fact that this symbol is the lead of a capabilities family is detected from the SHT_SUNW_capinfo section information. From this information the associated SHT_SUNW_capchain family is determined, and from this information ld.so.1 can look at each family member to determine which instance is the best candidate for the present system. elfdump(1) -H also displays these capability families: .... Capabilities Chain Section: .SUNW_capchain Capabilities family: memset chainndx symndx name 23 [565] memset 24 [17] memset%sun4u 25 [18] memset%sun4u-opl 26 [19] memset%sun4u-us3-hwcap1 27 [20] memset%sun4u-us3-hwcap2 28 [21] memset%sun4v-hwcap1 Capabilities family: _memcpy chainndx symndx name 15 [1771] memcpy 16 [11] memcpy%sun4u 17 [12] memcpy%sun4u-opl 18 [13] memcpy%sun4u-us3-hwcap1 19 [14] memcpy%sun4u-us3-hwcap2 20 [15] memcpy%sun4v-hwcap1 21 [16] memcpy%sun4v-hwcap2 This SHT_SUNW_capchain array can be cached within ld.so.1, and rewritten once a family member is chosen. Hence, subsequent lookups of the same symbol will be directed to the best family instance without having to reinspect all the family members. It is hoped that later versions of our compilers can create the SHT_SUNW_cap and SHT_SUNW_capinfo infrastructure as outlined above. Multiple versions of the same function can then be created within relocatable objects, and the link-editor will combine these, create the necessary SHT_SUNW_capchain entries, and provide for a dynamic symbol capabilities runtime environment. In the mean time, the link-editor has been updated to provide a means of conventing an object capabilities relocatable object into a symbol capabilities relocatable object. This is the means by which the above examples have been produced, and how an OSNet environment has been rebuilt to convent libc, libmd and libsoftcrypto to use symbol capabilities. ld(1) has a new -z symbolcap option. It is already possible for ld(1) to take a relocatable object, and add object capabilities via a mapfile. ld(1) can now take this object capabilities relocatable object, and convert it to a symbol capabilities object. For example, the steps used to create a symbol capabilities version of memcpy() might be: % cc -c memcpy.s % cat mapfile idcap = sun4u-opl; platcap = SUNW,SPARC-Enterprise % ld -r -o objcap.o -Mmapfile -Breduce memcpy.o % elfdump -H objcap.o Capabilities Section: .SUNW_cap Object Capabilities: index tag value [0] CA_SUNW_ID sun4u-opl [1] CA_SUNW_PLAT SUNW,SPARC-Enterprise % ld -r -o symcap.o -z symbolcap objcap.o % elfdump -H symcap.o Capabilities Section: .SUNW_cap Symbol Capabilities: index tag value [1] CA_SUNW_ID sun4u-opl [2] CA_SUNW_PLAT SUNW,SPARC-Enterprise Symbols: index value size type bind oth ver shndx name [13] 0x00000000 0x00000310 FUNC LOCL D 0 .text memcpy%sun4u-opl % elfdump -s symcap.o | fgrep memcpy [15] 0x00000340 0x0000076c FUNC LOCL D 0 .text memcpy%sun4u-opl [19] 0x00000000 0x00000000 FUNC GLOB D 0 UNDEF memcpy In a nutshell, ld(1) has: i. converted the SHT_SUNW_cap object capabilities definition to a symbol capabilities definition, ii. created a LOCAL symbol to associate with memcpy(), using the capabilities identifier supplied with the mapfile, iii. created an UNDEF (reference) symbol to associate with the original memcpy() definition, iv. created a SHT_SUNW_capinfo section to capture the association of memcpy with its capabilities group. Using the link-editor, together with mapfiles and -z symbolcap, instances of "psr" functions have been created and added to libc, libmd and libsoftcrypto. After the integration of this link-editor project (6918143), a follow on project will deliver the OSNet changes that use symbol capabilities. ------------------------------------------------------------------------------- The materials directory contains the changes for this project that have been applied to the Linker and Libraries Manual. Note, the LLM.pdf file only contains the updated pages that are relevant to this project, this isn't the whole book. Changes are diff-marked. ------------------------------------------------------------------------------- The following updates are provided. Release Binding: Patch/Micro All ELF updates that follow: Committed New section types: #define SHT_SUNW_capchain 0x6fffffef #define SHT_SUNW_capinfo 0x6ffffff0 New section definitions: typedef Elf32_Word Elf32_Capinfo; typedef Elf32_Word Elf32_Capchain; typedef Elf64_Xword Elf64_Capinfo; typedef Elf64_Word Elf64_Capchain; Capability section version numbers and reserved group tag: #define CAPINFO_NONE 0 #define CAPINFO_CURRENT 1 #define CAPINFO_NUM 2 #define CAPCHAIN_NONE 0 #define CAPCHAIN_CURRENT 1 #define CAPCHAIN_NUM 2 #define CAPINFO_SUNW_GLOB 0xff New Capabilities tags: #define CA_SUNW_HW_2 3 /* second hardware capabilities entry */ #define CA_SUNW_PLAT 4 /* platform capability entry */ #define CA_SUNW_MACH 5 /* machine capability entry */ #define CA_SUNW_ID 6 /* capability identifier */ New section aliases: typedef Elf64_Capinfo Capinfo; typedef Elf64_Capchain Capchain; typedef Elf32_Capinfo Capinfo; typedef Elf32_Capchain Capchain; New .dynamic tags: #define DT_SUNW_CAPINFO 0x60000018 /* capabilities symbols */ #define DT_SUNW_CAPCHAIN 0x6000001a /* capabilities chain info */ #define DT_SUNW_CAPCHAINENT 0x6000001d /* capabilities chain entry */ #define DT_SUNW_CAPCHAINSZ 0x6000001f /* capabilities chain size */ New .Syminfo flag: #define SYMINFO_FLG_CAP 0x0100 /* symbol is capabilities */ /* specific */ ld(1) -z symbolcap Convert a relocatable object that defines object capa- bilities into a relocatable object that defines symbol capabilities. See Converting Object Capabilities to Sym- bol Capabilities in Linker and Libraries Guide. New mapfile tokens: platcap = name; machcap = name; idcap = name; elfdump() No option changes, but the -H recognizes symbol capabilities and prints the capabilities and the associated symbols. ld.so.1 Recognizes the new symbol capabilities infrastructure, and provides new environment variables to control experimentation: LD_PLATCAP={name} LD_MACHCAP={name} LD_HWCAP=[+-]{token | number},... LD_SFCAP=[+-]{token | number},... LD_CAP_FILES=file,... -- Rod. From carlsonj@workingcode.com Wed Jan 20 13:38:14 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0KLcDqm021405 for ; Wed, 20 Jan 2010 13:38:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0KLcBRr009246; Wed, 20 Jan 2010 15:38:13 -0600 (CST) 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 <0KWK00003EROFA00@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Jan 2010 13:38:12 -0800 (PST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWK00F7WEROT1A0@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Jan 2010 13:38:12 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0KLNUCf028561; Wed, 20 Jan 2010 21:38:11 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay44i.sun.com with ESMTP id BT-MMP-6342204; Wed, 20 Jan 2010 21:38:05 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-3514428; Wed, 20 Jan 2010 21:38:05 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-12002039; Wed, 20 Jan 2010 21:38:04 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o0KLc3Ga017100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 16:38:03 -0500 (EST) Date: Wed, 20 Jan 2010 16:38:03 -0500 From: James Carlson Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities In-reply-to: <4B5763A7.4050206@sun.com> To: Rod.Evans@sun.com Cc: psarc-ext@sun.com Message-id: <4B5777BB.90203@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=3.2/5.0, scanned in 0.226sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B5763A7.4050206@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 419 Rod Evans wrote: > In other words, we can take the contents of all our libc_psr libraries and > put them in one libc.so.1. Then we can then throw away the /platform > symlinked psr libraries. Wicked cool. Any chance this (or some extension of it) could eventually do in the loopback-mounted libc.so.1 on x86 as well, or is that too hard? -- James Carlson 42.703N 71.076W From Rod.Evans@sun.com Wed Jan 20 13:53:03 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0KLr3fN021669 for ; Wed, 20 Jan 2010 13:53:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0KLr2Ja024977 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 20 Jan 2010 13:53:03 -0800 (PST) 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 <0KWK0012HFGEB600@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 20 Jan 2010 13:53:02 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWK00FC4FGET7B0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 20 Jan 2010 13:53:02 -0800 (PST) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0KLr2rD118901; Wed, 20 Jan 2010 13:53:02 -0800 (PST) Date: Wed, 20 Jan 2010 13:52:48 -0800 From: Rod Evans Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities In-reply-to: <4B5777BB.90203@workingcode.com> To: James Carlson Cc: psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <4B577B30.10209@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B5763A7.4050206@sun.com> <4B5777BB.90203@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20091207 Thunderbird/3.0 Status: RO Content-Length: 1600 On 01/20/10 01:38 PM, James Carlson wrote: > Rod Evans wrote: >> In other words, we can take the contents of all our libc_psr libraries and >> put them in one libc.so.1. Then we can then throw away the /platform >> symlinked psr libraries. > > Wicked cool. Any chance this (or some extension of it) could eventually > do in the loopback-mounted libc.so.1 on x86 as well, or is that too hard? Possibly. Although the amount of processing to instantiate a symbol capabilities instance is much less than the present "psr" library search, there's still some cost. The loop-back mount model, once instantiated, incurs no cost on each process that uses the library. There are ideas being floated in regards the loop-back mount model, as the draw-back of making the original libc "invisible" are well known. Whether symbol capabilities can replace this are unknown as yet. However, some of the extensions provided with this project (the expanded capabilities descriptors that provide for platform and machine names for example) are expected to be useful in any new mechanism. This model fits between the "psr" model and the loop-back mount model, and should provide a more flexible, and easier to create, model for general users to add symbol capabilities instances. But, there's more to come to address the loop-back mount model .... I'll be back. -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks! From carlsonj@workingcode.com Thu Jan 21 04:50:32 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0LCoV1P026283 for ; Thu, 21 Jan 2010 04:50:32 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0LCoVjI000222; Thu, 21 Jan 2010 04:50:31 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWL00A2NL07UU00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Jan 2010 04:50:31 -0800 (PST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWL00MYOL06LI50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Jan 2010 04:50:30 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0LCknVZ006080; Thu, 21 Jan 2010 12:50:30 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay43i.sun.com with ESMTP id BT-MMP-10922622; Thu, 21 Jan 2010 12:50:27 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-4323162; Thu, 21 Jan 2010 12:50:27 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-22383847; Thu, 21 Jan 2010 12:50:27 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o0LCoMcs000389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 07:50:26 -0500 (EST) Date: Thu, 21 Jan 2010 07:50:22 -0500 From: James Carlson Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities In-reply-to: <4B577B30.10209@sun.com> To: Rod.Evans@sun.com Cc: psarc-ext@sun.com Message-id: <4B584D8E.1060007@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=3.2/5.0, scanned in 0.272sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B5763A7.4050206@sun.com> <4B5777BB.90203@workingcode.com> <4B577B30.10209@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 491 Rod Evans wrote: > This model fits between the "psr" model and the loop-back mount model, > and should provide a more flexible, and easier to create, model > for general users to add symbol capabilities instances. OK. Yes, it does look a lot simpler and more general than the previous capabilities mechanism. > But, there's more to come to address the loop-back mount model .... > I'll be back. Good to hear. -- James Carlson 42.703N 71.076W From Rod.Evans@sun.com Fri Jan 22 16:23:12 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0N0NCDb017978 for ; Fri, 22 Jan 2010 16:23:12 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0N0NCY4024757 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 22 Jan 2010 16:23:12 -0800 (PST) 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 <0KWO00509BQOH100@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 22 Jan 2010 16:23:12 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWO00KXCBQO0270@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 22 Jan 2010 16:23:12 -0800 (PST) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0N0NC2R593970 for ; Fri, 22 Jan 2010 16:23:12 -0800 (PST) Date: Fri, 22 Jan 2010 16:22:59 -0800 From: Rod Evans Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities In-reply-to: <4B584D8E.1060007@workingcode.com> Cc: psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <4B5A4163.1010202@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B5763A7.4050206@sun.com> <4B5777BB.90203@workingcode.com> <4B577B30.10209@sun.com> <4B584D8E.1060007@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Thunderbird/3.0 Status: RO Content-Length: 981 I've just been pointed to the following mail, which can be found in the opensolaris-arc archives, but isn't in the PSARC mail log. Apologies for missing this, but I'm not subscribed to the opensolaris-arc alias. > Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities > From: "Richard L. Hamilton" > Date: Wed, 20 Jan 2010 22:07:13 -0800 (PST) > To: opensolaris-arc@opensolaris.org > > why not carry on to the logical conclusion, i.e. full fat binaries > (x86/amd64/sparcv7/sparcv9)? > -- This message posted from opensolaris.org Fat binaries, although brought up now and then, haven't triggered a large amount of interest. This project is more about the micro optimization of single class objects. -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks! From ro@CeBiTec.Uni-Bielefeld.DE Tue Jan 26 06:03:22 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0QE3LNV024629 for ; Tue, 26 Jan 2010 06:03:22 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0QE3IEv001310; Tue, 26 Jan 2010 06:03:21 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWU00J0RXPKRX00@brm-avmta-1.central.sun.com>; Tue, 26 Jan 2010 07:03:20 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWU00KK8XPI7BB0@brm-avmta-1.central.sun.com>; Tue, 26 Jan 2010 07:03:18 -0700 (MST) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0QDsMll019372; Tue, 26 Jan 2010 14:03:18 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-5555504; Tue, 26 Jan 2010 14:03:17 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-12574648; Tue, 26 Jan 2010 14:03:15 +0000 (Z) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([129.70.160.84] [129.70.160.84]) by relay4i.sun.com with ESMTP id BT-MMP-47359116; Tue, 26 Jan 2010 14:03:15 +0000 (Z) Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 8C0D7DBE; Tue, 26 Jan 2010 15:03:14 +0100 (CET) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SfTiJD0wYXK5; Tue, 26 Jan 2010 15:03:12 +0100 (CET) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 90201DBC; Tue, 26 Jan 2010 15:03:12 +0100 (CET) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.3+Sun/8.14.3/Submit) id o0QE3CjQ013540; Tue, 26 Jan 2010 15:03:12 +0100 (MET) Date: Tue, 26 Jan 2010 15:03:12 +0100 From: Rainer Orth Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities In-reply-to: <4B5763A7.4050206@sun.com> To: Rod.Evans@sun.com Cc: psarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: amavisd-new at cebitec.uni-bielefeld.de X-Antispam: No, score=3.2/5.0, scanned in 1.770sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B5763A7.4050206@sun.com> X-Authentication-warning: manam.CeBiTec.Uni-Bielefeld.DE: ro set sender to ro@CeBiTec.Uni-Bielefeld.DE using -f User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) Status: RO Content-Length: 1297 Rod Evans writes: > The compiler engineers have also asked for a means of selecting between a > family of functions contained within the same dynamic object. Each family > member is compiled differently to use various capabilities, where these > capabilities can be provided by different systems. Not this case, but how is one supposed to use this directly from the compiler/assembler without linker mapfiles? Might be interesting to add support to GCC in the future. A couple of other questions: * You're currently using v1 mapfile syntax in the LLM excerpt. I suppose this is because this case requests patch/micro binding, but it should state the v2 syntax, too. * In the example on p.76 of the LLM, what happens if the machine provides e.g. both MMX and SSE. Which instance of foo will be used in this case? I suppose there is a similar ordering like the one described on p.380 (descending order of capability values), but is this supposed to be documented or implementation defined? * Does LD_CAP_FILES match the file names of shared objects, or their SONAMEs, exact or substring match? Thanks. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Rod.Evans@sun.com Tue Jan 26 09:41:00 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0QHexp3027929 for ; Tue, 26 Jan 2010 09:40:59 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0QHex8Y023986 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 26 Jan 2010 10:40:59 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KWV00H0T7SBEU00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 26 Jan 2010 10:40:59 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWV000BJ7S8J1D0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 26 Jan 2010 10:40:57 -0700 (MST) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0QHesoa415456; Tue, 26 Jan 2010 09:40:54 -0800 (PST) Date: Tue, 26 Jan 2010 09:40:44 -0800 From: Rod Evans Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities In-reply-to: To: Rainer Orth Cc: psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <4B5F291C.6090801@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B5763A7.4050206@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Thunderbird/3.0 Status: RO Content-Length: 2987 On 01/26/10 06:03 AM, Rainer Orth wrote: > Rod Evans writes: > >> The compiler engineers have also asked for a means of selecting between a >> family of functions contained within the same dynamic object. Each family >> member is compiled differently to use various capabilities, where these >> capabilities can be provided by different systems. > > Not this case, but how is one supposed to use this directly from the > compiler/assembler without linker mapfiles? Might be interesting to add > support to GCC in the future. The exact method would be up to the compilers. The high-level idea was that some new compiler option(s) might lead the compiler to generate one or more variants of the functions within a source file. For example, if a source file contained foo(), they might generate a foo%sun4u and foo%sun4v, and associate each function with a set of capabilities that were directed by the compilers options. The generated source file would have the same ELF infrastructure as a relocatable object generated with -z symbolcap. ld(1) could then process this file, as it does now with -z symbolcap generated files, and create the associated dynamic object - no mapfiles need be involved. > A couple of other questions: > > * You're currently using v1 mapfile syntax in the LLM excerpt. I > suppose this is because this case requests patch/micro binding, but it > should state the v2 syntax, too. You've caught us in the middle of two projects, the symbol capabilities and the new mapfile implementation (PSARC/2009/688). The LLM materials for this case don't include changes for 2009/688. However, we have updates for the LLM for 2009/688, and they are being merged together as we speak. The final LLM will have all examples using the v2 syntax. Symbol capabilities can be driven off of v1 or v2 mapfile syntax. > * In the example on p.76 of the LLM, what happens if the machine > provides e.g. both MMX and SSE. Which instance of foo will be used in > this case? I suppose there is a similar ordering like the one > described on p.380 (descending order of capability values), but is > this supposed to be documented or implementation defined? It should be clearer than it is :-) The largest value wins. > * Does LD_CAP_FILES match the file names of shared objects, or their > SONAMEs, exact or substring match? The doc states: The most flexible means of defining LD_CAP_FILES is to use the base name of the required files. $ LD_HWCAP=-sse2 LD_CAP_FILES=libfoo.so,libbar.so ./main The files base name is the SONAME. The implementation actually uses the base name, full path name, or even alias names (symlinks) to match any LD_CAP_FILES requirements. -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks! From Rod.Evans@sun.com Thu Feb 4 07:34:45 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o14FYjwW028034 for ; Thu, 4 Feb 2010 07:34:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o14FYgFE006232 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 4 Feb 2010 07:34:45 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KXB00405PXWUG00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 04 Feb 2010 08:34:44 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KXB000HVPXWA230@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 04 Feb 2010 08:34:44 -0700 (MST) Received: from Macintosh-3.local (punchin-rie.SFBay.Sun.COM [10.7.251.250]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o14FYhp0395459 for ; Thu, 04 Feb 2010 07:34:43 -0800 (PST) Date: Thu, 04 Feb 2010 07:34:43 -0800 From: Rod Evans Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities In-reply-to: <4B584D8E.1060007@workingcode.com> To: psarc-ext@sun.com Message-id: <4B6AE913.2010105@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B5763A7.4050206@sun.com> <4B5777BB.90203@workingcode.com> <4B577B30.10209@sun.com> <4B584D8E.1060007@workingcode.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 352 This case was approved at PSARC Feb 3rd 2010. http://sac.sfbay/Archives/Minutes/PSARC/2010/20100203.html -- Rod Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks! From Rod.Evans@sun.com Thu Feb 4 11:43:59 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o14FYjwW028034 for ; Thu, 4 Feb 2010 07:34:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o14FYgFE006232 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 4 Feb 2010 07:34:45 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KXB00405PXWUG00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 04 Feb 2010 08:34:44 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KXB000HVPXWA230@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 04 Feb 2010 08:34:44 -0700 (MST) Received: from Macintosh-3.local (punchin-rie.SFBay.Sun.COM [10.7.251.250]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o14FYhp0395459 for ; Thu, 04 Feb 2010 07:34:43 -0800 (PST) Date: Thu, 04 Feb 2010 07:34:43 -0800 From: Rod Evans Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities In-reply-to: <4B584D8E.1060007@workingcode.com> To: psarc-ext@sun.com Message-id: <4B6AE913.2010105@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B5763A7.4050206@sun.com> <4B5777BB.90203@workingcode.com> <4B577B30.10209@sun.com> <4B584D8E.1060007@workingcode.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 352 This case was approved at PSARC Feb 3rd 2010. http://sac.sfbay/Archives/Minutes/PSARC/2010/20100203.html -- Rod Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!