From sacadmin Mon Jan 7 11:10:30 2008 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 m07JAUES015604 for ; Mon, 7 Jan 2008 11:10:30 -0800 (PST) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m07JAUJg584379; Mon, 7 Jan 2008 11:10:30 -0800 (PST) Message-ID: <47827904.6030300@sun.com> Date: Mon, 07 Jan 2008 11:09:56 -0800 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems Inc. User-Agent: Thunderbird 2.0.0.6 (X11/20071119) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com, psarc-ext@sun.com Subject: 2008/006: make ld(1) -z combreloc become default behavior Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3408 ------------------------------------------------------------------------ I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. ------------------------------------------------------------------------ The link-editors -z combreloc flag combines individual relocation sections (like .rela.data and .rela.bss) into one relocation table .SUNW_reloc. This concatenation of the standard relocation tables allows ld(1) to sort all data relocations so that the symbol lookup cost, from ld.so.1(1), is minimized. The option has existed since Solaris 7 (4044285), and its use has been enforced for OSnet components via check_rtime. Linux took the same option, but went one step further and made the functionality the default behavior for gld as of version 2.13. Gld produces .rel.dyn sections, whereas ld produces .SUNW_reloc sections - however, the section names are never referenced, so their names aren't particularly meaningful. Gld also provides the additional -z nocombreloc option just in case. ld(1) should make -z combreloc the default behavior when creating a final object (ie., an executable or shared object). The -z combreloc option will still be recognized, but effectively ignored. A new -z nocombreloc option will be added to disable the relocation section concatenation. ------------------------------------------------------------------------ The ld(1) man page will be updated to add: Synopsis ld [-64] [-a | -r] [-b] [-Bdirect | nodirect] ..... [-z altexec64] [-z combreloc | nocombreloc ] [-z defs | nodefs] ..... Options The following options are supported: ..... -z combreloc | nocombreloc By default, the link-editor combines multiple relocation sections when building executables or shared objects. This section combination differs from relocatable objects, in which relocation sections are maintained in a one-to-one relationship with the sections to which the relocations must be applied. The -z nocombreloc option disables this merging of relocation sections, and preserves the one-to-one relationship found in the ori- ginal relocatable objects. The link-editor sorts the entries of data relocation sections by their symbol reference. This sorting reduces runtime symbol lookup. When multiple relocation sec- tions are combined, this sorting produces the least pos- sible relocation overhead when objects are loaded into memory, and speeds the runtime loading of dynamic objects. Historically, the individual relocation sections were carried over to any executable or shared object, and the -z combreloc option was required to enable the reloca- tion section merging previously described. Relocation section merging is now the default. The -z combreloc option is still accepted for the benefit of old build environments, but the option is unnecessary, and has no effect. ------------------------------------------------------------------------ Release Binding: Patch/Micro ld -znocombreloc option Committed -- Rod. From Rod.Evans@sun.com Mon Jan 7 11:10:36 2008 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 m07JAZj4015616 for ; Mon, 7 Jan 2008 11:10:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m07JASNX002798 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 8 Jan 2008 03:10:34 +0800 (SGT) 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 <0JUA00103FXJD000@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 07 Jan 2008 11:10:31 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUA008AWFXIVMF0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 07 Jan 2008 11:10:30 -0800 (PST) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m07JAUJg584379; Mon, 07 Jan 2008 11:10:30 -0800 (PST) Date: Mon, 07 Jan 2008 11:09:56 -0800 From: Rod Evans Subject: 2008/006: make ld(1) -z combreloc become default behavior To: psarc@sac.sfbay.sun.com, psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <47827904.6030300@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.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 3408 ------------------------------------------------------------------------ I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. ------------------------------------------------------------------------ The link-editors -z combreloc flag combines individual relocation sections (like .rela.data and .rela.bss) into one relocation table .SUNW_reloc. This concatenation of the standard relocation tables allows ld(1) to sort all data relocations so that the symbol lookup cost, from ld.so.1(1), is minimized. The option has existed since Solaris 7 (4044285), and its use has been enforced for OSnet components via check_rtime. Linux took the same option, but went one step further and made the functionality the default behavior for gld as of version 2.13. Gld produces .rel.dyn sections, whereas ld produces .SUNW_reloc sections - however, the section names are never referenced, so their names aren't particularly meaningful. Gld also provides the additional -z nocombreloc option just in case. ld(1) should make -z combreloc the default behavior when creating a final object (ie., an executable or shared object). The -z combreloc option will still be recognized, but effectively ignored. A new -z nocombreloc option will be added to disable the relocation section concatenation. ------------------------------------------------------------------------ The ld(1) man page will be updated to add: Synopsis ld [-64] [-a | -r] [-b] [-Bdirect | nodirect] ..... [-z altexec64] [-z combreloc | nocombreloc ] [-z defs | nodefs] ..... Options The following options are supported: ..... -z combreloc | nocombreloc By default, the link-editor combines multiple relocation sections when building executables or shared objects. This section combination differs from relocatable objects, in which relocation sections are maintained in a one-to-one relationship with the sections to which the relocations must be applied. The -z nocombreloc option disables this merging of relocation sections, and preserves the one-to-one relationship found in the ori- ginal relocatable objects. The link-editor sorts the entries of data relocation sections by their symbol reference. This sorting reduces runtime symbol lookup. When multiple relocation sec- tions are combined, this sorting produces the least pos- sible relocation overhead when objects are loaded into memory, and speeds the runtime loading of dynamic objects. Historically, the individual relocation sections were carried over to any executable or shared object, and the -z combreloc option was required to enable the reloca- tion section merging previously described. Relocation section merging is now the default. The -z combreloc option is still accepted for the benefit of old build environments, but the option is unnecessary, and has no effect. ------------------------------------------------------------------------ Release Binding: Patch/Micro ld -znocombreloc option Committed -- Rod. From sacadmin Mon Jan 7 11:05:43 2008 Received: from oxpoly.sfbay.sun.com (oxpoly [129.146.228.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m07J5hTZ015493; Mon, 7 Jan 2008 11:05:43 -0800 (PST) Received: from oxpoly.sfbay.sun.com (localhost [127.0.0.1]) by oxpoly.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m07J2gFt025670; Mon, 7 Jan 2008 11:02:42 -0800 (PST) Received: (from rie@localhost) by oxpoly.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m07J2gru025665; Mon, 7 Jan 2008 11:02:42 -0800 (PST) Date: Mon, 7 Jan 2008 11:02:42 -0800 (PST) From: Rod Evans Message-Id: <200801071902.m07J2gru025665@oxpoly.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: make ld(1) -z combreloc become default behavior [PSARC/2008/006 Self Review] Status: RO Content-Length: 583 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: make ld(1) -z combreloc become default behavior 1.2. Name of Document Author/Supplier: Author: Rod Evans 1.3 Date of This Document: 07 January, 2008 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: Automatic 6.6. ARC Exposure: open From glenn.skinner@sun.com Tue Jan 8 11:02:43 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m08J2hUn021314 for ; Tue, 8 Jan 2008 11:02:43 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m08J2gEI007437; Tue, 8 Jan 2008 11:02:43 -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 <0JUC004A7A8EDE00@brm-avmta-1.central.sun.com>; Tue, 08 Jan 2008 12:02:38 -0700 (MST) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUC007WVA8B1TE0@brm-avmta-1.central.sun.com>; Tue, 08 Jan 2008 12:02:35 -0700 (MST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m08J2YRe009158; Tue, 08 Jan 2008 11:02:34 -0800 (PST) Date: Tue, 08 Jan 2008 11:02:34 -0800 (PST) From: Glenn Skinner Subject: Re: 2008/006: make ld(1) -z combreloc become default behavior To: psarc-ext@sun.com, Rod.Evans@sun.com Reply-to: Glenn Skinner Message-id: <200801081902.m08J2YRe009158@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: Beu91IQPDj9b0fa7H0fpyg== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 610 Date: Mon, 07 Jan 2008 11:09:56 -0800 From: Rod Evans Subject: 2008/006: make ld(1) -z combreloc become default behavior ... ld(1) should make -z combreloc the default behavior when creating a final object (ie., an executable or shared object). The -z combreloc option will still be recognized, but effectively ignored. A new -z nocombreloc option will be added to disable the relocation section concatenation. Under what circumstances might one wish to use the old behavior? What is the compatibility impact of switching this default? -- Glenn From Rod.Evans@sun.com Tue Jan 8 11:22:51 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m08JMoEF022105 for ; Tue, 8 Jan 2008 11:22:51 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m08JMdQ6013414; Tue, 8 Jan 2008 19:22:48 GMT 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 <0JUC00A03B5ZLL00@nwk-avmta-2.sfbay.sun.com>; Tue, 08 Jan 2008 11:22:47 -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 <0JUC0043ZB5YSTA0@nwk-avmta-2.sfbay.sun.com>; Tue, 08 Jan 2008 11:22:47 -0800 (PST) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m08JMkEo755942; Tue, 08 Jan 2008 11:22:46 -0800 (PST) Date: Tue, 08 Jan 2008 11:22:12 -0800 From: Rod Evans Subject: Re: 2008/006: make ld(1) -z combreloc become default behavior In-reply-to: <200801081902.m08J2YRe009158@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <4783CD64.5010101@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.2.0.264296 References: <200801081902.m08J2YRe009158@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1621 Glenn Skinner wrote: > Date: Mon, 07 Jan 2008 11:09:56 -0800 > From: Rod Evans > Subject: 2008/006: make ld(1) -z combreloc become default behavior > > ... > ld(1) should make -z combreloc the default behavior when creating a > final object (ie., an executable or shared object). The -z combreloc > option will still be recognized, but effectively ignored. A new > -z nocombreloc option will be added to disable the relocation section > concatenation. > > Under what circumstances might one wish to use the old behavior? I have no idea why anyone would want to use the old behavior. The relocation tables within dynamic objects have always been concatenated together, and are read by ld.so.1 as one contiguous table. Creating a single table doesn't change how ld.so.1 reads it, it just allows the table to be better optimized (sorted). But, like so many historic artifacts, there's always the possibly that someone, somewhere would like the old layout. -z nocombreloc provides this back door - plus, gld provides the option too, so in a way we're conforming with gld use. > What is the compatibility impact of switching this default? None that we're aware of. We've used the option ourself throughout the OS for years, and have advised others to do so too. As the gld folks have made it their default, I suspect they've found no compatibility issues either. Given this background, making the behavior default rather than trying to keep asking developers to use -z combreloc will help the startup performance of all dynamic objects (a bit). -- Rod. From jek3@sun.com Tue Jan 8 13:35:51 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m08LZo3R027222 for ; Tue, 8 Jan 2008 13:35:51 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m08LZcAx003928; Tue, 8 Jan 2008 21:35:47 GMT 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 <0JUC00F0BHBKZ600@nwk-avmta-2.sfbay.sun.com>; Tue, 08 Jan 2008 13:35:44 -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 <0JUC00FDKHBKVL00@nwk-avmta-2.sfbay.sun.com>; Tue, 08 Jan 2008 13:35:44 -0800 (PST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m08LZhLK779326; Tue, 08 Jan 2008 13:35:43 -0800 (PST) Date: Tue, 08 Jan 2008 11:34:58 -1000 From: Joseph Kowalski Subject: Re: 2008/006: make ld(1) -z combreloc become default behavior In-reply-to: <4783CD64.5010101@sun.com> To: Rod.Evans@sun.com Cc: Glenn Skinner , psarc-ext@sun.com Message-id: <4783EC82.7020709@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801081902.m08J2YRe009158@ivrel.sfbay.sun.com> <4783CD64.5010101@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1929 Rod Evans wrote: > Glenn Skinner wrote: >> Date: Mon, 07 Jan 2008 11:09:56 -0800 >> From: Rod Evans >> Subject: 2008/006: make ld(1) -z combreloc become default behavior >> >> ... >> ld(1) should make -z combreloc the default behavior when creating a >> final object (ie., an executable or shared object). The -z >> combreloc >> option will still be recognized, but effectively ignored. A new >> -z nocombreloc option will be added to disable the relocation >> section >> concatenation. >> >> Under what circumstances might one wish to use the old behavior? > > I have no idea why anyone would want to use the old behavior. The > relocation tables within dynamic objects have always been concatenated > together, and are read by ld.so.1 as one contiguous table. Creating a > single table doesn't change how ld.so.1 reads it, it just allows the > table to be better optimized (sorted). But, like so many historic > artifacts, > there's always the possibly that someone, somewhere would like the > old layout. -z nocombreloc provides this back door - plus, gld provides > the option too, so in a way we're conforming with gld use. > >> What is the compatibility impact of switching this default? > > None that we're aware of. We've used the option ourself throughout the > OS for years, and have advised others to do so too. As the gld folks > have made it their default, I suspect they've found no compatibility > issues either. Given this background, making the behavior default > rather than trying to keep asking developers to use -z combreloc will > help the startup performance of all dynamic objects (a bit). > So, just for completeness, please add a explicit "release binding" to the case. It seems that the above provides the rationale for a "Patch Binding" while changing defaults is usually something reserved for "Minor Binding". - thanks! - jek3 From Rod.Evans@sun.com Wed Jan 9 08:36:55 2008 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 m09GatHG022132 for ; Wed, 9 Jan 2008 08:36:55 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09GarUR005687; Wed, 9 Jan 2008 09:36:54 -0700 (MST) 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 <0JUD00K17Y5EXP00@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 08:36:50 -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 <0JUD00IY9Y5CPC40@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Jan 2008 08:36:48 -0800 (PST) Received: from Macintosh-2.local (punchin-rie.SFBay.Sun.COM [10.7.251.250]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m09GamBq882425; Wed, 09 Jan 2008 08:36:48 -0800 (PST) Date: Wed, 09 Jan 2008 08:36:47 -0800 From: Rod Evans Subject: Re: 2008/006: make ld(1) -z combreloc become default behavior In-reply-to: <4783EC82.7020709@sun.com> To: Joseph Kowalski Cc: Glenn Skinner , psarc-ext@sun.com Message-id: <4784F81F.5010901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801081902.m08J2YRe009158@ivrel.sfbay.sun.com> <4783CD64.5010101@sun.com> <4783EC82.7020709@sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 448 Joseph Kowalski wrote: > So, just for completeness, please add a explicit "release binding" to the > case. It seems that the above provides the rationale for a "Patch Binding" > while changing defaults is usually something reserved for "Minor Binding". It's already stated: ------------------------------------------------------------------------ Release Binding: Patch/Micro ld -znocombreloc option Committed -- Rod