From sacadmin Wed Aug 4 15:36:29 2010 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 o74MaTGn016216; Wed, 4 Aug 2010 15:36:29 -0700 (PDT) Received: (from ab196087@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o74MaThG016212; Wed, 4 Aug 2010 15:36:29 -0700 (PDT) Date: Wed, 4 Aug 2010 15:36:29 -0700 (PDT) From: Ali Bahrami Message-Id: <201008042236.o74MaThG016212@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Link-editor guidance [PSARC/2010/312 FastTrack timeout 8/11/2010] Status: RO Content-Length: 593 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Link-editor guidance 1.2. Name of Document Author/Supplier: Author: Ali Bahrami 1.3 Date of This Document: 04 August, 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: on 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Ali.Bahrami@oracle.com Wed Aug 4 16:23:36 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 o74NNZuZ018075 for ; Wed, 4 Aug 2010 16:23:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o74NNZge002170 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Aug 2010 18:23:35 -0500 (CDT) 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 <0L6N00503IBBGG00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Aug 2010 16:23:35 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L6N001BXIBB4A20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Aug 2010 16:23:35 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o74NNYF0021557 for ; Wed, 04 Aug 2010 23:23:34 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o73F4YCd023485 for ; Wed, 04 Aug 2010 23:23:29 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt354.oracle.com with ESMTP id 467124121280964135; Wed, 04 Aug 2010 16:22:15 -0700 Received: from [172.20.25.67] (/10.85.25.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Aug 2010 16:22:15 -0700 Date: Wed, 04 Aug 2010 17:19:44 -0600 From: Ali Bahrami Subject: PSARC 2010/312 Link-editor guidance To: PSARC-ext@sun.com Message-id: <4C59F590.70802@Oracle.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 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C59F673.0226:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100719 Lightning/1.0b2 Thunderbird/3.1 Status: RO Content-Length: 15641 I am sponsoring the following fasttrack for myself --- timeout 8/11/2010. It adds three new options to the Solaris link-editor (ld). A copy of the original (ld.1.orig) and new (ld.1.new) ld manpage, as well as diffs (ld.1.diffs) can be found in the case materials. Release Binding: Patch/Micro -z guidance: Committed -z fatal-warnings/--fatal-warnings Committed -z nofatal-warnings/--no-fatal-warnings Committed -------------------------------------------------------------------------- The new options are: -z guidance The link-editor has many options that are highly recommended, but which are not on by default. When the user enables the -z guidance feature, ld will issue "guidance" warning (non-fatal) messages to recommend options or changes that will result in a better object. -z fatal-warnings, --fatal-warnings ld warnings are advisory, in that the link-editor continues on to build the output object. If -z fatal-warnings is set, warnings are treated as fatal conditions --- the output object is not built, and a non-zero exit status is returned. This feature is useful for building code that is held to very high standards (such as the core Solaris OS/net consolidation), since it will prevent inadvertent errors from slipping past developers. It should be noted that this includes the warnings issued by -z guidance. --fatal-warnings is the name used by the GNU ld for their version of this feature. We will accept it as an alias for -z fatal-warnings. -z nofatal-warnings, --no-fatal-warnings Undo the effect of -z fatal-warnings, and revert to non-fatal warnings. This is the default, and so should be rarely needed, but is useful in the context of the LD_OPTIONS environment variable to override the use -f -z fatal-warnings from within a Makefile: % LD_OPTIONS=-D-znofatal-warnings make --no-fatal-warnings is the name used by GNU ld for their version of this feature. We will accept it as an alias for -z nofatal-warnings. I have successfully built the OS/net with -z guidance, and -z fatal-warnings turned on. I was able to get a completely clean build with only a modest set of changes (167 lines changed: 54 ins; 46 del; 67 mod). This reflects the fact that we already do extensive checking of the objects in the OS/net (via check_rtime). In general, the changes fall into the following categories: - Suppress guidance in known cases where the flagged behavior needs to be retained. - Some applications pull in dependencies they do not directly require for the benefit of plugins they later load, and the dependencies for those plugins are not completely specified. Correcting the plugin dependencies allows these extras to be dropped. Although not part of this case, I expect to integrate these changes in a future project, and to apply -z guidance and -z fatal-warnings to the OS/net by default. This should make it easier for developers to spot difficulties earlier in the coding process. -------------------------------------------------------------------------- Example: The following example demonstrates how the guidance feature is intended to work. We will build a shared object that has a variety of shortcomings: - Does not specify all it's dependencies - Specifies dependencies it does not use - Does not use direct bindings - Uses a version 1 mapfile - Contains relocations to the readonly allocable text (not PIC) This scenario is sadly very common --- many shared objects have one or more of these issues. % cat hello.c #include #include void hello(void) { printf("hello user %d\n", getpid()); } % cat mapfile.v1 # This version 1 mapfile will trigger a guidance message % cc -c hello.c % ld -o hello.so -G -M mapfile.v1 hello.o -lelf As you can see, the operation completes without error, resulting in a usable object. However, turning on guidance reveals a number of things that could be better: ld -o hello.so -G -M mapfile.v1 hello.o -lelf -zguidance ld: guidance: version 2 mapfile syntax recommended: mapfile.v1 ld: guidance: -z lazyload option recommended before first dependency ld: guidance: -B direct or -z direct option recommended before first dependency Undefined first referenced symbol in file getpid hello.o (symbol belongs to implicit dependency /lib/libc.so.1) printf hello.o (symbol belongs to implicit dependency /lib/libc.so.1) ld: warning: symbol referencing errors ld: guidance: -z defs option recommended for shared objects ld: guidance: removal of unused dependency recommended: libelf.so.1 warning: Text relocation remains referenced against symbol offset in file .rodata1 (section) 0xa hello.o getpid 0x4 hello.o printf 0xf hello.o ld: guidance: position independent (PIC) code recommended for shared objects ld: guidance: see ld(1) -z guidance for more information Given the explicit advice in the above guidance messages, it is relatively easy to modify the example to do the right things: % cat mapfile.v2 # This version 2 mapfile will not trigger a guidance message $mapfile_version 2 % cc -c -Kpic hello.c % ld -o hello.so -G -Bdirect -M mapfile.v2 hello.o -lc -zguidance Although unlikely, one might imagine a scenario in which it was desired to use non-PIC code, and accept the price of performing relocations at runtime on the readonly allocable text segment: % cc -c hello.c % ld -o hello.so -G -Bdirect -M mapfile.v2 hello.o -lc -zguidance warning: Text relocation remains referenced against symbol offset in file .rodata1 (section) 0xa hello.o getpid 0x4 hello.o printf 0xf hello.o ld: guidance: position independent (PIC) code recommended for shared objects ld: guidance: see ld(1) -z guidance for more information It is easy to disable that specific guidance warning without losing the overall benefit from allowing the remainder of the guidance feature to operate: % ld -o hello.so -G -Bdirect -M mapfile.v2 hello.o -lc -zguidance=notext -------------------------------------------------------------------------- Rationale: The information that follows below is not strictly part of this case, but provides background information that may prove useful to the reader in understanding the evolution in thinking and design that led to the implementation of -z guidance and -z fatal-warnings in their current form. The Solaris link-editor is one of the older Unix commands. Over the years, applications have grown in size and complexity, and the ELF system has evolved to provide them with tools needed to manage their growing requirements. Features such as lazy loading, and direct bindings have been added. In an ideal world, many of these options would be defaults, with rarely used options that allow the user to turn them off. However, the reality is exactly the reverse: For backward compatibility, these features are all options that must be explicitly turned on by the user. This has led to a situation in which most applications do not take advantage of the many improvements that have been made in linking over the last 20 years. If their code seems to link and run without issue, what motivation does a developer have to read a complex manpage, absorb the information provided, choose the features that matter for their application, and apply them? Experience shows that only the most motivated and diligent programmers will make that effort. We would like to do something to make it easier for everyone else. There have been many conversations over the years regarding this issue, and how to address it. They break down along the following lines: Change ld defaults Since the world would be a better place if these ld features were defaults, the ls command could simply be changed to make them so. This idea is simple, elegant, and impossible. Doing so would break a large number of existing applications, including those of ISVs, big customers, a plethora of existing open source packages. In each case, the owner of that code may choose to follow our lead and fix their code, or they may view it as an invitation to reconsider their commitment to our platform. Backward compatibility, and our installed base of working software, is one of our greatest assets, and not something to be lightly put at risk. Breaking backward compatibility at this level of the system is likely to do more harm than good. New link-editor One might create a new linker command, not called 'ld', leaving the old command as it is. The new one could use the same code as 'ld', but would offer only modern options, with the proper defaults for features such as direct binding. The resulting link-editor would be a pleasure to use. However, the approach is doomed to niche status. There is a vast pile of exiting code in the world built around the 'ld' command, that reaches back to the 1970's. ld use is embedded in large and unknown numbers of makefiles, and is used by name by compilers that execute it. A Unix link-editor that is not named 'ld' will not find a majority audience no matter how good it might be. Finally, a new linker command will eventually cease to be new, and will accumulate its own burden of backward compatibility issues. An option to make 'ld' do the right things automatically This line of reasoning is best summarized by a CR filed in 2005, entitled 6239804 make it easier for ld(1) to do what's best The idea is to have a '-z best' option that unchains ld from its backward compatibility commitment, and allows it to turn on the "best" set of features, as determined by the authors of 'ld'. The specific set of features enabled by -z best would be subject to change over time, as requirements change. This idea is more realistic than the other two, but has not been implemented to date because it has some significant issues. - The -z best proposal assumes that the user can turn it on, and trust it to select good options without the user needing to be aware of the options being applied. This is a fallacy. Features such as direct bindings require the user to do some analysis to ensure that the resulting program will still operate properly. - A user who is willing to do the work to know what -z best does is capable of turning on those features directly, and therefore gains little benefit from -z best. - The intent is that when a user opts into -z best, that they understand that z best is subject to sometimes incompatible evolution. Experience teaches us that this won't work. People will use this feature, the meaning of -z best will change, code that used to build will fail, and then there will be complaints and demands to retract the change. When (not if) this occurs, we will of course defend our actions, and point at the disclaimer. We'll win some of those debates, and lose others. Ultimately, we'll end up with -z best2 (-z better), or other compromises, and our goal of simplifying the world will have failed. - The -z best idea rolls up a set of features that may or may not be related to each other into a unit that must be taken wholesale, or not at all. It could be that only a subset of what it does is compatible with a given application, in which case the user is expected to abandon -z best and instead set the options that apply to their application directly. In doing so, they lose one of the benefits of -z best, that if you use it, future versions of ld may choose a different set of options, and automatically improve the object through the act of rebuilding it. I draw two conclusions from the above history: (1) For a link-editor, backward compatibility is vital. If a given command line linked your application 10 years ago, you have every reason to expect that it will link today, assuming that the libraries you're linking against are still available and compatible with their previous interfaces. (2) For an application of any size or complexity, there is no substitute for the work involved in examining the code and determining which linker options apply and which do not. These options are largely orthogonal to each other, and there are reasonable reasons not to use any or all of them, even in modern applications. It is a mistake to tie them together. The idea for -z guidance came from consideration of these points. By decoupling the advice from the act of taking the advice, we can retain the good aspects of -z best while avoiding its pitfalls: - -z guidance gives advice, but the decision to take that advice remains with the user who must evaluate its merit and make a decision to take it or not. As such, we are free to change the specific guidance given in future releases of ld, without breaking existing applications. The only fallout from this will be some new warnings in the build output, which can be ignored or dealt with at the user's convenience. - It does not couple the various features given into a single "take it or leave it" option, meaning that there will be no need to offer "-zguidance2", or other such variants when things change over time. - The user is given the flexibility to disable specific categories of guidance without losing the benefit of others, including those that might be added to future versions of the system. Although -z fatal-warnings stands on its own as a useful feature, it is of particular interest in combination with -z guidance. Used together, the guidance turns from advice to hard requirement: The user must either make the suggested change, or explicitly reject the advice, in order to get a build. This is valuable in environments with high coding standards. In addition, it gains us an additional point of compatibility with the GNU link-editor. From garrett@damore.org Wed Aug 4 19:50:02 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 o752o2TE021553 for ; Wed, 4 Aug 2010 19:50:02 -0700 (PDT) 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 o752o2kI019300 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Aug 2010 19:50:02 -0700 (PDT) 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 <0L6N0000DRVE6M00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Aug 2010 20:50:02 -0600 (MDT) 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 <0L6N00MEDRVB4SC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Aug 2010 20:49:59 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o752nAWZ013531 for ; Thu, 05 Aug 2010 02:49:58 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-1130664 for PSARC-ext@sun.com; Thu, 05 Aug 2010 02:49:58 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-76897383 for PSARC-ext@sun.com; Thu, 05 Aug 2010 02:49:58 +0000 (Z) Received: from oproxy3-pub.bluehost.com ([69.89.21.8] [69.89.21.8]) by relay1i.sun.com id BT-MMP-14964218 for PSARC-ext@sun.com; Thu, 05 Aug 2010 02:49:57 +0000 (Z) Received: (qmail 30795 invoked by uid 0); Thu, 05 Aug 2010 02:49:57 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy3.bluehost.com with SMTP; Thu, 05 Aug 2010 02:49:57 +0000 Received: from 250.sub-97-14-170.myvzw.com ([97.14.170.250] helo=localhost) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OgqVy-0005Mo-9X; Wed, 04 Aug 2010 20:49:57 -0600 Date: Wed, 04 Aug 2010 22:47:09 -0400 From: "Garrett D'Amore" Subject: Re: PSARC 2010/312 Link-editor guidance To: Ali Bahrami , PSARC-ext@sun.com Message-id: Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Date:Subject:Message-ID:From:To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=fQkcL8N/KlGnEw0FwRhFKR2T9Sr0NkrHuxi980WIsWx6iy5xpjmCpxTSwfUTl/q+PMDu6VMYM+SN07zVAgfXPFxNB9dYyWU+h+4nx4MJhGK1XtPHDRjTPzb9MaO7/8r0; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 97.14.170.250 authed with garrett+damore.org} X-Antispam: No, score=3.5/5.0, scanned in 0.304sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Status: RO Content-Length: 21882 KzEsIGFuZCArMSB0byBhIGZ1dHVyZSBwcm9qZWN0IHRvIHVzZSB0aGVzZSBmbGFncyBpbiBPTi4g IFRoYW5rcyEKCiAgLSBHYXJyZXR0CgpBbGkgQmFocmFtaSA8QWxpLkJhaHJhbWlAb3JhY2xlLmNv bT4gd3JvdGU6Cgo+SSBhbSBzcG9uc29yaW5nIHRoZSBmb2xsb3dpbmcgZmFzdHRyYWNrIGZvciBt eXNlbGYgLS0tIHRpbWVvdXQgOC8xMS8yMDEwLgo+SXQgYWRkcyB0aHJlZSBuZXcgb3B0aW9ucyB0 byB0aGUgU29sYXJpcyBsaW5rLWVkaXRvciAobGQpLgo+Cj5BIGNvcHkgb2YgdGhlIG9yaWdpbmFs IChsZC4xLm9yaWcpIGFuZCBuZXcgKGxkLjEubmV3KSBsZCBtYW5wYWdlLCBhcyB3ZWxsCj5hcyBk aWZmcyAobGQuMS5kaWZmcykgY2FuIGJlIGZvdW5kIGluIHRoZSBjYXNlIG1hdGVyaWFscy4KPgo+ UmVsZWFzZSBCaW5kaW5nOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGF0Y2gvTWlj cm8KPi16IGd1aWRhbmNlOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENvbW1p dHRlZAo+LXogZmF0YWwtd2FybmluZ3MvLS1mYXRhbC13YXJuaW5ncyAgICAgICAgICAgICAgQ29t bWl0dGVkCj4teiBub2ZhdGFsLXdhcm5pbmdzLy0tbm8tZmF0YWwtd2FybmluZ3MgICAgICAgICBD b21taXR0ZWQKPgo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPlRoZSBuZXcgb3B0aW9ucyBhcmU6Cj4KPiAg ICAgLXogZ3VpZGFuY2UKPgo+ICAgICAgICAgVGhlIGxpbmstZWRpdG9yIGhhcyBtYW55IG9wdGlv bnMgdGhhdCBhcmUgaGlnaGx5Cj4gICAgICAgICByZWNvbW1lbmRlZCwgYnV0IHdoaWNoIGFyZSBu b3Qgb24gYnkgZGVmYXVsdC4gV2hlbgo+ICAgICAgICAgdGhlIHVzZXIgZW5hYmxlcyB0aGUgLXog Z3VpZGFuY2UgZmVhdHVyZSwgbGQgd2lsbCBpc3N1ZQo+ICAgICAgICAgImd1aWRhbmNlIiB3YXJu aW5nIChub24tZmF0YWwpIG1lc3NhZ2VzIHRvIHJlY29tbWVuZAo+ICAgICAgICAgb3B0aW9ucyBv ciBjaGFuZ2VzIHRoYXQgd2lsbCByZXN1bHQgaW4gYSBiZXR0ZXIgb2JqZWN0Lgo+Cj4KPiAgICAg LXogZmF0YWwtd2FybmluZ3MsIC0tZmF0YWwtd2FybmluZ3MKPgo+ICAgICAgICAgbGQgd2Fybmlu Z3MgYXJlIGFkdmlzb3J5LCBpbiB0aGF0IHRoZSBsaW5rLWVkaXRvciBjb250aW51ZXMKPiAgICAg ICAgIG9uIHRvIGJ1aWxkIHRoZSBvdXRwdXQgb2JqZWN0LiBJZiAteiBmYXRhbC13YXJuaW5ncyBp cyBzZXQsCj4gICAgICAgICB3YXJuaW5ncyBhcmUgdHJlYXRlZCBhcyBmYXRhbCBjb25kaXRpb25z IC0tLSB0aGUgb3V0cHV0IG9iamVjdAo+ICAgICAgICAgaXMgbm90IGJ1aWx0LCBhbmQgYSBub24t emVybyBleGl0IHN0YXR1cyBpcyByZXR1cm5lZC4gVGhpcwo+ICAgICAgICAgZmVhdHVyZSBpcyB1 c2VmdWwgZm9yIGJ1aWxkaW5nIGNvZGUgdGhhdCBpcyBoZWxkIHRvIHZlcnkKPiAgICAgICAgIGhp Z2ggc3RhbmRhcmRzIChzdWNoIGFzIHRoZSBjb3JlIFNvbGFyaXMgT1MvbmV0IGNvbnNvbGlkYXRp b24pLAo+ICAgICAgICAgc2luY2UgaXQgd2lsbCBwcmV2ZW50IGluYWR2ZXJ0ZW50IGVycm9ycyBm cm9tIHNsaXBwaW5nIHBhc3QKPiAgICAgICAgIGRldmVsb3BlcnMuIEl0IHNob3VsZCBiZSBub3Rl ZCB0aGF0IHRoaXMgaW5jbHVkZXMgdGhlIHdhcm5pbmdzCj4gICAgICAgICBpc3N1ZWQgYnkgLXog Z3VpZGFuY2UuCj4KPiAgICAgICAgIC0tZmF0YWwtd2FybmluZ3MgaXMgdGhlIG5hbWUgdXNlZCBi eSB0aGUgR05VIGxkIGZvciB0aGVpciB2ZXJzaW9uIG9mCj4gICAgICAgICB0aGlzIGZlYXR1cmUu IFdlIHdpbGwgYWNjZXB0IGl0IGFzIGFuIGFsaWFzIGZvciAteiBmYXRhbC13YXJuaW5ncy4KPgo+ Cj4gICAgIC16IG5vZmF0YWwtd2FybmluZ3MsIC0tbm8tZmF0YWwtd2FybmluZ3MKPgo+ICAgICAg ICAgVW5kbyB0aGUgZWZmZWN0IG9mIC16IGZhdGFsLXdhcm5pbmdzLCBhbmQgcmV2ZXJ0IHRvIG5v bi1mYXRhbAo+ICAgICAgICAgd2FybmluZ3MuIFRoaXMgaXMgdGhlIGRlZmF1bHQsIGFuZCBzbyBz aG91bGQgYmUgcmFyZWx5IG5lZWRlZCwKPiAgICAgICAgIGJ1dCBpcyB1c2VmdWwgaW4gdGhlIGNv bnRleHQgb2YgdGhlIExEX09QVElPTlMgZW52aXJvbm1lbnQKPiAgICAgICAgIHZhcmlhYmxlIHRv IG92ZXJyaWRlIHRoZSB1c2UgLWYgLXogZmF0YWwtd2FybmluZ3MgZnJvbSB3aXRoaW4KPiAgICAg ICAgIGEgTWFrZWZpbGU6Cj4KPiAgICAgICAgICAgICAlIExEX09QVElPTlM9LUQtem5vZmF0YWwt d2FybmluZ3MgbWFrZQo+Cj4gICAgICAgICAtLW5vLWZhdGFsLXdhcm5pbmdzIGlzIHRoZSBuYW1l IHVzZWQgYnkgR05VIGxkIGZvciB0aGVpciB2ZXJzaW9uIG9mCj4gICAgICAgICB0aGlzIGZlYXR1 cmUuIFdlIHdpbGwgYWNjZXB0IGl0IGFzIGFuIGFsaWFzIGZvciAteiBub2ZhdGFsLXdhcm5pbmdz Lgo+Cj5JIGhhdmUgc3VjY2Vzc2Z1bGx5IGJ1aWx0IHRoZSBPUy9uZXQgd2l0aCAteiBndWlkYW5j ZSwgYW5kIC16IGZhdGFsLXdhcm5pbmdzCj50dXJuZWQgb24uIEkgd2FzIGFibGUgdG8gZ2V0IGEg Y29tcGxldGVseSBjbGVhbiBidWlsZCB3aXRoIG9ubHkgYSBtb2Rlc3QKPnNldCBvZiBjaGFuZ2Vz ICgxNjcgbGluZXMgY2hhbmdlZDogNTQgaW5zOyA0NiBkZWw7IDY3IG1vZCkuIFRoaXMgcmVmbGVj dHMgdGhlCj5mYWN0IHRoYXQgd2UgYWxyZWFkeSBkbyBleHRlbnNpdmUgY2hlY2tpbmcgb2YgdGhl IG9iamVjdHMgaW4gdGhlIE9TL25ldAo+KHZpYSBjaGVja19ydGltZSkuIEluIGdlbmVyYWwsIHRo ZSBjaGFuZ2VzIGZhbGwgaW50byB0aGUgZm9sbG93aW5nIGNhdGVnb3JpZXM6Cj4KPiAgICAgLSBT dXBwcmVzcyBndWlkYW5jZSBpbiBrbm93biBjYXNlcyB3aGVyZSB0aGUgZmxhZ2dlZCBiZWhhdmlv cgo+ICAgICAgIG5lZWRzIHRvIGJlIHJldGFpbmVkLgo+Cj4gICAgIC0gU29tZSBhcHBsaWNhdGlv bnMgcHVsbCBpbiBkZXBlbmRlbmNpZXMgdGhleSBkbyBub3QgZGlyZWN0bHkgcmVxdWlyZQo+ICAg ICAgIGZvciB0aGUgYmVuZWZpdCBvZiBwbHVnaW5zIHRoZXkgbGF0ZXIgbG9hZCwgYW5kIHRoZSBk ZXBlbmRlbmNpZXMgZm9yCj4gICAgICAgdGhvc2UgcGx1Z2lucyBhcmUgbm90IGNvbXBsZXRlbHkg c3BlY2lmaWVkLiBDb3JyZWN0aW5nIHRoZSBwbHVnaW4KPiAgICAgICBkZXBlbmRlbmNpZXMgYWxs b3dzIHRoZXNlIGV4dHJhcyB0byBiZSBkcm9wcGVkLgo+Cj5BbHRob3VnaCBub3QgcGFydCBvZiB0 aGlzIGNhc2UsIEkgZXhwZWN0IHRvIGludGVncmF0ZSB0aGVzZSBjaGFuZ2VzCj5pbiBhIGZ1dHVy ZSBwcm9qZWN0LCBhbmQgdG8gYXBwbHkgLXogZ3VpZGFuY2UgYW5kIC16IGZhdGFsLXdhcm5pbmdz IHRvCj50aGUgT1MvbmV0IGJ5IGRlZmF1bHQuIFRoaXMgc2hvdWxkIG1ha2UgaXQgZWFzaWVyIGZv ciBkZXZlbG9wZXJzIHRvIHNwb3QKPmRpZmZpY3VsdGllcyBlYXJsaWVyIGluIHRoZSBjb2Rpbmcg cHJvY2Vzcy4KPgo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPkV4YW1wbGU6Cj4KPlRoZSBmb2xsb3dpbmcg ZXhhbXBsZSBkZW1vbnN0cmF0ZXMgaG93IHRoZSBndWlkYW5jZSBmZWF0dXJlCj5pcyBpbnRlbmRl ZCB0byB3b3JrLiBXZSB3aWxsIGJ1aWxkIGEgc2hhcmVkIG9iamVjdCB0aGF0Cj5oYXMgYSB2YXJp ZXR5IG9mIHNob3J0Y29taW5nczoKPgo+ICAgICAtIERvZXMgbm90IHNwZWNpZnkgYWxsIGl0J3Mg ZGVwZW5kZW5jaWVzCj4gICAgIC0gU3BlY2lmaWVzIGRlcGVuZGVuY2llcyBpdCBkb2VzIG5vdCB1 c2UKPiAgICAgLSBEb2VzIG5vdCB1c2UgZGlyZWN0IGJpbmRpbmdzCj4gICAgIC0gVXNlcyBhIHZl cnNpb24gMSBtYXBmaWxlCj4gICAgIC0gQ29udGFpbnMgcmVsb2NhdGlvbnMgdG8gdGhlIHJlYWRv bmx5IGFsbG9jYWJsZSB0ZXh0IChub3QgUElDKQo+Cj5UaGlzIHNjZW5hcmlvIGlzIHNhZGx5IHZl cnkgY29tbW9uIC0tLSBtYW55IHNoYXJlZCBvYmplY3RzCj5oYXZlIG9uZSBvciBtb3JlIG9mIHRo ZXNlIGlzc3Vlcy4KPgo+ICAgICAlIGNhdCBoZWxsby5jCj4gICAgICNpbmNsdWRlIDxzdGRpby5o Pgo+ICAgICAjaW5jbHVkZSA8dW5pc3RkLmg+Cj4KPiAgICAgdm9pZAo+ICAgICBoZWxsbyh2b2lk KQo+ICAgICB7Cj4gICAgICAgICAgICAgcHJpbnRmKCJoZWxsbyB1c2VyICVkXG4iLCBnZXRwaWQo KSk7Cj4gICAgIH0KPgo+ICAgICAlIGNhdCBtYXBmaWxlLnYxCj4gICAgICMgVGhpcyB2ZXJzaW9u IDEgbWFwZmlsZSB3aWxsIHRyaWdnZXIgYSBndWlkYW5jZSBtZXNzYWdlCj4KPiAgICAgJSBjYyAt YyBoZWxsby5jCj4gICAgICUgbGQgLW8gaGVsbG8uc28gLUcgLU0gbWFwZmlsZS52MSBoZWxsby5v IC1sZWxmCj4KPkFzIHlvdSBjYW4gc2VlLCB0aGUgb3BlcmF0aW9uIGNvbXBsZXRlcyB3aXRob3V0 IGVycm9yLCByZXN1bHRpbmcKPmluIGEgdXNhYmxlIG9iamVjdC4gSG93ZXZlciwgdHVybmluZyBv biBndWlkYW5jZSByZXZlYWxzIGEgbnVtYmVyCj5vZiB0aGluZ3MgdGhhdCBjb3VsZCBiZSBiZXR0 ZXI6Cj4KPiAgICAgbGQgLW8gaGVsbG8uc28gLUcgLU0gbWFwZmlsZS52MSBoZWxsby5vIC1sZWxm IC16Z3VpZGFuY2UKPiAgICAgbGQ6IGd1aWRhbmNlOiB2ZXJzaW9uIDIgbWFwZmlsZSBzeW50YXgg cmVjb21tZW5kZWQ6IG1hcGZpbGUudjEKPiAgICAgbGQ6IGd1aWRhbmNlOiAteiBsYXp5bG9hZCBv cHRpb24gcmVjb21tZW5kZWQgYmVmb3JlIGZpcnN0IGRlcGVuZGVuY3kKPiAgICAgbGQ6IGd1aWRh bmNlOiAtQiBkaXJlY3Qgb3IgLXogZGlyZWN0IG9wdGlvbiByZWNvbW1lbmRlZCBiZWZvcmUKPiAg ICAgICAgICAgICAgICAgICBmaXJzdCBkZXBlbmRlbmN5Cj4gICAgIFVuZGVmaW5lZCAgICAgICAg ICAgICAgICAgICAgICAgZmlyc3QgcmVmZXJlbmNlZAo+ICAgICAgc3ltYm9sICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBpbiBmaWxlCj4gICAgIGdldHBpZCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGhlbGxvLm8gIChzeW1ib2wgYmVsb25ncyB0byBpbXBsaWNpdAo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVwZW5kZW5jeSAvbGli L2xpYmMuc28uMSkKPiAgICAgcHJpbnRmICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGVs bG8ubyAgKHN5bWJvbCBiZWxvbmdzIHRvIGltcGxpY2l0Cj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXBlbmRlbmN5IC9saWIvbGliYy5zby4xKQo+ ICAgICBsZDogd2FybmluZzogc3ltYm9sIHJlZmVyZW5jaW5nIGVycm9ycwo+ICAgICBsZDogZ3Vp ZGFuY2U6IC16IGRlZnMgb3B0aW9uIHJlY29tbWVuZGVkIGZvciBzaGFyZWQgb2JqZWN0cwo+ICAg ICBsZDogZ3VpZGFuY2U6IHJlbW92YWwgb2YgdW51c2VkIGRlcGVuZGVuY3kgcmVjb21tZW5kZWQ6 IGxpYmVsZi5zby4xCj4gICAgIHdhcm5pbmc6IFRleHQgcmVsb2NhdGlvbiByZW1haW5zICAgICAg ICAgICAgICAgIHJlZmVyZW5jZWQKPiAgICAgICAgIGFnYWluc3Qgc3ltYm9sICAgICAgICAgICAg ICAgICAgb2Zmc2V0ICAgICAgaW4gZmlsZQo+ICAgICAucm9kYXRhMSAoc2VjdGlvbikgICAgICAg ICAgICAgICAgICAweGEgICAgICAgICBoZWxsby5vCj4gICAgIGdldHBpZCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDB4NCAgICAgICAgIGhlbGxvLm8KPiAgICAgcHJpbnRmICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMHhmICAgICAgICAgaGVsbG8ubwo+ICAgICBsZDogZ3VpZGFu Y2U6IHBvc2l0aW9uIGluZGVwZW5kZW50IChQSUMpIGNvZGUgcmVjb21tZW5kZWQgZm9yIHNoYXJl ZCBvYmplY3RzCj4gICAgIGxkOiBndWlkYW5jZTogc2VlIGxkKDEpIC16IGd1aWRhbmNlIGZvciBt b3JlIGluZm9ybWF0aW9uCj4KPkdpdmVuIHRoZSBleHBsaWNpdCBhZHZpY2UgaW4gdGhlIGFib3Zl IGd1aWRhbmNlIG1lc3NhZ2VzLCBpdCBpcwo+cmVsYXRpdmVseSBlYXN5IHRvIG1vZGlmeSB0aGUg ZXhhbXBsZSB0byBkbyB0aGUgcmlnaHQgdGhpbmdzOgo+Cj4gICAgICUgY2F0IG1hcGZpbGUudjIK PiAgICAgIyBUaGlzIHZlcnNpb24gMiBtYXBmaWxlIHdpbGwgbm90IHRyaWdnZXIgYSBndWlkYW5j ZSBtZXNzYWdlCj4gICAgICRtYXBmaWxlX3ZlcnNpb24gMgo+Cj4gICAgICUgY2MgLWMgLUtwaWMg aGVsbG8uYwo+ICAgICAlIGxkIC1vIGhlbGxvLnNvIC1HIC1CZGlyZWN0IC1NIG1hcGZpbGUudjIg aGVsbG8ubyAtbGMgLXpndWlkYW5jZQo+Cj5BbHRob3VnaCB1bmxpa2VseSwgb25lIG1pZ2h0IGlt YWdpbmUgYSBzY2VuYXJpbyBpbiB3aGljaCBpdCB3YXMgZGVzaXJlZAo+dG8gdXNlIG5vbi1QSUMg Y29kZSwgYW5kIGFjY2VwdCB0aGUgcHJpY2Ugb2YgcGVyZm9ybWluZyByZWxvY2F0aW9ucyBhdAo+ cnVudGltZSBvbiB0aGUgcmVhZG9ubHkgYWxsb2NhYmxlIHRleHQgc2VnbWVudDoKPgo+ICAgICAl IGNjIC1jIGhlbGxvLmMKPiAgICAgJSBsZCAtbyBoZWxsby5zbyAtRyAtQmRpcmVjdCAtTSBtYXBm aWxlLnYyIGhlbGxvLm8gLWxjIC16Z3VpZGFuY2UKPiAgICAgd2FybmluZzogVGV4dCByZWxvY2F0 aW9uIHJlbWFpbnMgICAgICAgICAgICAgICAgcmVmZXJlbmNlZAo+ICAgICAgICAgYWdhaW5zdCBz eW1ib2wgICAgICAgICAgICAgICAgICBvZmZzZXQgICAgICBpbiBmaWxlCj4gICAgIC5yb2RhdGEx IChzZWN0aW9uKSAgICAgICAgICAgICAgICAgIDB4YSAgICAgICAgIGhlbGxvLm8KPiAgICAgZ2V0 cGlkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMHg0ICAgICAgICAgaGVsbG8ubwo+ICAg ICBwcmludGYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAweGYgICAgICAgICBoZWxsby5v Cj4gICAgIGxkOiBndWlkYW5jZTogcG9zaXRpb24gaW5kZXBlbmRlbnQgKFBJQykgY29kZSByZWNv bW1lbmRlZCBmb3Igc2hhcmVkIG9iamVjdHMKPiAgICAgbGQ6IGd1aWRhbmNlOiBzZWUgbGQoMSkg LXogZ3VpZGFuY2UgZm9yIG1vcmUgaW5mb3JtYXRpb24KPgo+SXQgaXMgZWFzeSB0byBkaXNhYmxl IHRoYXQgc3BlY2lmaWMgZ3VpZGFuY2Ugd2FybmluZyB3aXRob3V0IGxvc2luZyB0aGUKPm92ZXJh bGwgYmVuZWZpdCBmcm9tIGFsbG93aW5nIHRoZSByZW1haW5kZXIgb2YgdGhlIGd1aWRhbmNlIGZl YXR1cmUgdG8KPm9wZXJhdGU6Cj4KPiAgICAgJSBsZCAtbyBoZWxsby5zbyAtRyAtQmRpcmVjdCAt TSBtYXBmaWxlLnYyIGhlbGxvLm8gLWxjIC16Z3VpZGFuY2U9bm90ZXh0Cj4KPgo+Cj4KPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCj5SYXRpb25hbGU6Cj4KPlRoZSBpbmZvcm1hdGlvbiB0aGF0IGZvbGxvd3Mg YmVsb3cgaXMgbm90IHN0cmljdGx5IHBhcnQgb2YgdGhpcwo+Y2FzZSwgYnV0IHByb3ZpZGVzIGJh Y2tncm91bmQgaW5mb3JtYXRpb24gdGhhdCBtYXkgcHJvdmUgdXNlZnVsCj50byB0aGUgcmVhZGVy IGluIHVuZGVyc3RhbmRpbmcgdGhlIGV2b2x1dGlvbiBpbiB0aGlua2luZyBhbmQgZGVzaWduCj50 aGF0IGxlZCB0byB0aGUgaW1wbGVtZW50YXRpb24gb2YgLXogZ3VpZGFuY2UgYW5kIC16IGZhdGFs LXdhcm5pbmdzCj5pbiB0aGVpciBjdXJyZW50IGZvcm0uCj4KPiAgICBUaGUgU29sYXJpcyBsaW5r LWVkaXRvciBpcyBvbmUgb2YgdGhlIG9sZGVyIFVuaXggY29tbWFuZHMuIE92ZXIKPnRoZSB5ZWFy cywgYXBwbGljYXRpb25zIGhhdmUgZ3Jvd24gaW4gc2l6ZSBhbmQgY29tcGxleGl0eSwgYW5kIHRo ZSBFTEYKPnN5c3RlbSBoYXMgZXZvbHZlZCB0byBwcm92aWRlIHRoZW0gd2l0aCB0b29scyBuZWVk ZWQgdG8gbWFuYWdlIHRoZWlyCj5ncm93aW5nIHJlcXVpcmVtZW50cy4gRmVhdHVyZXMgc3VjaCBh cyBsYXp5IGxvYWRpbmcsIGFuZCBkaXJlY3QgYmluZGluZ3MKPmhhdmUgYmVlbiBhZGRlZC4gSW4g YW4gaWRlYWwgd29ybGQsIG1hbnkgb2YgdGhlc2Ugb3B0aW9ucyB3b3VsZCBiZSBkZWZhdWx0cywK PndpdGggcmFyZWx5IHVzZWQgb3B0aW9ucyB0aGF0IGFsbG93IHRoZSB1c2VyIHRvIHR1cm4gdGhl bSBvZmYuIEhvd2V2ZXIsIHRoZQo+cmVhbGl0eSBpcyBleGFjdGx5IHRoZSByZXZlcnNlOiBGb3Ig YmFja3dhcmQgY29tcGF0aWJpbGl0eSwgdGhlc2UgZmVhdHVyZXMKPmFyZSBhbGwgb3B0aW9ucyB0 aGF0IG11c3QgYmUgZXhwbGljaXRseSB0dXJuZWQgb24gYnkgdGhlIHVzZXIuIFRoaXMgaGFzCj5s ZWQgdG8gYSBzaXR1YXRpb24gaW4gd2hpY2ggbW9zdCBhcHBsaWNhdGlvbnMgZG8gbm90IHRha2Ug YWR2YW50YWdlIG9mCj50aGUgbWFueSBpbXByb3ZlbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBp biBsaW5raW5nIG92ZXIgdGhlIGxhc3QgMjAKPnllYXJzLiBJZiB0aGVpciBjb2RlIHNlZW1zIHRv IGxpbmsgYW5kIHJ1biB3aXRob3V0IGlzc3VlLCB3aGF0IG1vdGl2YXRpb24KPmRvZXMgYSBkZXZl bG9wZXIgaGF2ZSB0byByZWFkIGEgY29tcGxleCBtYW5wYWdlLCBhYnNvcmIgdGhlIGluZm9ybWF0 aW9uCj5wcm92aWRlZCwgY2hvb3NlIHRoZSBmZWF0dXJlcyB0aGF0IG1hdHRlciBmb3IgdGhlaXIg YXBwbGljYXRpb24sIGFuZCBhcHBseQo+dGhlbT8gRXhwZXJpZW5jZSBzaG93cyB0aGF0IG9ubHkg dGhlIG1vc3QgbW90aXZhdGVkIGFuZCBkaWxpZ2VudCBwcm9ncmFtbWVycwo+d2lsbCBtYWtlIHRo YXQgZWZmb3J0LiBXZSB3b3VsZCBsaWtlIHRvIGRvIHNvbWV0aGluZyB0byBtYWtlIGl0IGVhc2ll cgo+Zm9yIGV2ZXJ5b25lIGVsc2UuCj4KPlRoZXJlIGhhdmUgYmVlbiBtYW55IGNvbnZlcnNhdGlv bnMgb3ZlciB0aGUgeWVhcnMgcmVnYXJkaW5nIHRoaXMgaXNzdWUsCj5hbmQgaG93IHRvIGFkZHJl c3MgaXQuIFRoZXkgYnJlYWsgZG93biBhbG9uZyB0aGUgZm9sbG93aW5nIGxpbmVzOgo+Cj4gICAg IENoYW5nZSBsZCBkZWZhdWx0cwo+ICAgICAgICAgU2luY2UgdGhlIHdvcmxkIHdvdWxkIGJlIGEg YmV0dGVyIHBsYWNlIGlmIHRoZXNlIGxkIGZlYXR1cmVzIHdlcmUKPiAgICAgICAgIGRlZmF1bHRz LCB0aGUgbHMgY29tbWFuZCBjb3VsZCBzaW1wbHkgYmUgY2hhbmdlZCB0byBtYWtlIHRoZW0gc28u Cj4KPiAgICAgICAgIFRoaXMgaWRlYSBpcyBzaW1wbGUsIGVsZWdhbnQsIGFuZCBpbXBvc3NpYmxl LiBEb2luZyBzbyB3b3VsZAo+ICAgICAgICAgYnJlYWsgYSBsYXJnZSBudW1iZXIgb2YgZXhpc3Rp bmcgYXBwbGljYXRpb25zLCBpbmNsdWRpbmcgdGhvc2Ugb2YKPiAgICAgICAgIElTVnMsIGJpZyBj dXN0b21lcnMsIGEgcGxldGhvcmEgb2YgZXhpc3Rpbmcgb3BlbiBzb3VyY2UgcGFja2FnZXMuCj4g ICAgICAgICBJbiBlYWNoIGNhc2UsIHRoZSBvd25lciBvZiB0aGF0IGNvZGUgbWF5IGNob29zZSB0 byBmb2xsb3cgb3VyIGxlYWQKPiAgICAgICAgIGFuZCBmaXggdGhlaXIgY29kZSwgb3IgdGhleSBt YXkgdmlldyBpdCBhcyBhbiBpbnZpdGF0aW9uIHRvIHJlY29uc2lkZXIKPiAgICAgICAgIHRoZWly IGNvbW1pdG1lbnQgdG8gb3VyIHBsYXRmb3JtLiBCYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBhbmQg b3VyCj4gICAgICAgICBpbnN0YWxsZWQgYmFzZSBvZiB3b3JraW5nIHNvZnR3YXJlLCBpcyBvbmUg b2Ygb3VyIGdyZWF0ZXN0IGFzc2V0cywKPiAgICAgICAgIGFuZCBub3Qgc29tZXRoaW5nIHRvIGJl IGxpZ2h0bHkgcHV0IGF0IHJpc2suIEJyZWFraW5nIGJhY2t3YXJkCj4gICAgICAgICBjb21wYXRp YmlsaXR5IGF0IHRoaXMgbGV2ZWwgb2YgdGhlIHN5c3RlbSBpcyBsaWtlbHkgdG8gZG8gbW9yZQo+ ICAgICAgICAgaGFybSB0aGFuIGdvb2QuCj4KPiAgICAgTmV3IGxpbmstZWRpdG9yCj4gICAgICAg ICBPbmUgbWlnaHQgY3JlYXRlIGEgbmV3IGxpbmtlciBjb21tYW5kLCBub3QgY2FsbGVkICdsZCcs IGxlYXZpbmcgdGhlCj4gICAgICAgICBvbGQgY29tbWFuZCBhcyBpdCBpcy4gVGhlIG5ldyBvbmUg Y291bGQgdXNlIHRoZSBzYW1lIGNvZGUgYXMgJ2xkJywKPiAgICAgICAgIGJ1dCB3b3VsZCBvZmZl ciBvbmx5IG1vZGVybiBvcHRpb25zLCB3aXRoIHRoZSBwcm9wZXIgZGVmYXVsdHMgZm9yCj4gICAg ICAgICBmZWF0dXJlcyBzdWNoIGFzIGRpcmVjdCBiaW5kaW5nLgo+Cj4gICAgICAgICBUaGUgcmVz dWx0aW5nIGxpbmstZWRpdG9yIHdvdWxkIGJlIGEgcGxlYXN1cmUgdG8gdXNlLiBIb3dldmVyLAo+ ICAgICAgICAgdGhlIGFwcHJvYWNoIGlzIGRvb21lZCB0byBuaWNoZSBzdGF0dXMuIFRoZXJlIGlz IGEgdmFzdCBwaWxlCj4gICAgICAgICBvZiBleGl0aW5nIGNvZGUgaW4gdGhlIHdvcmxkIGJ1aWx0 IGFyb3VuZCB0aGUgJ2xkJyBjb21tYW5kLCB0aGF0Cj4gICAgICAgICByZWFjaGVzIGJhY2sgdG8g dGhlIDE5NzAncy4gbGQgdXNlIGlzIGVtYmVkZGVkIGluIGxhcmdlIGFuZCB1bmtub3duCj4gICAg ICAgICBudW1iZXJzIG9mIG1ha2VmaWxlcywgYW5kIGlzIHVzZWQgYnkgbmFtZSBieSBjb21waWxl cnMgdGhhdAo+ICAgICAgICAgZXhlY3V0ZSBpdC4gQSBVbml4IGxpbmstZWRpdG9yIHRoYXQgaXMg bm90IG5hbWVkICdsZCcgd2lsbCBub3QgZmluZAo+ICAgICAgICAgYSBtYWpvcml0eSBhdWRpZW5j ZSBubyBtYXR0ZXIgaG93IGdvb2QgaXQgbWlnaHQgYmUuCj4KPiAgICAgICAgIEZpbmFsbHksIGEg bmV3IGxpbmtlciBjb21tYW5kIHdpbGwgZXZlbnR1YWxseSBjZWFzZSB0byBiZQo+ICAgICAgICAg bmV3LCBhbmQgd2lsbCBhY2N1bXVsYXRlIGl0cyBvd24gYnVyZGVuIG9mIGJhY2t3YXJkIGNvbXBh dGliaWxpdHkKPiAgICAgICAgIGlzc3Vlcy4KPgo+ICAgICBBbiBvcHRpb24gdG8gbWFrZSAnbGQn IGRvIHRoZSByaWdodCB0aGluZ3MgYXV0b21hdGljYWxseQo+Cj4gICAgICAgICBUaGlzIGxpbmUg b2YgcmVhc29uaW5nIGlzIGJlc3Qgc3VtbWFyaXplZCBieSBhIENSIGZpbGVkCj4gICAgICAgICBp biAyMDA1LCBlbnRpdGxlZAo+Cj4gICAgICAgICAgICAgNjIzOTgwNCBtYWtlIGl0IGVhc2llciBm b3IgbGQoMSkgdG8gZG8gd2hhdCdzIGJlc3QKPgo+ICAgICAgICAgVGhlIGlkZWEgaXMgdG8gaGF2 ZSBhICcteiBiZXN0JyBvcHRpb24gdGhhdCB1bmNoYWlucyBsZCBmcm9tCj4gICAgICAgICBpdHMg YmFja3dhcmQgY29tcGF0aWJpbGl0eSBjb21taXRtZW50LCBhbmQgYWxsb3dzIGl0IHRvIHR1cm4K PiAgICAgICAgIG9uIHRoZSAiYmVzdCIgc2V0IG9mIGZlYXR1cmVzLCBhcyBkZXRlcm1pbmVkIGJ5 IHRoZSBhdXRob3JzCj4gICAgICAgICBvZiAnbGQnLiBUaGUgc3BlY2lmaWMgc2V0IG9mIGZlYXR1 cmVzIGVuYWJsZWQgYnkgLXogYmVzdCB3b3VsZAo+ICAgICAgICAgYmUgc3ViamVjdCB0byBjaGFu Z2Ugb3ZlciB0aW1lLCBhcyByZXF1aXJlbWVudHMgY2hhbmdlLgo+Cj4gICAgICAgICBUaGlzIGlk ZWEgaXMgbW9yZSByZWFsaXN0aWMgdGhhbiB0aGUgb3RoZXIgdHdvLCBidXQgaGFzIG5vdCBiZWVu Cj4gICAgICAgICBpbXBsZW1lbnRlZCB0byBkYXRlIGJlY2F1c2UgaXQgaGFzIHNvbWUgc2lnbmlm aWNhbnQgaXNzdWVzLgo+Cj4gICAgICAgICAgICAgLSBUaGUgLXogYmVzdCBwcm9wb3NhbCBhc3N1 bWVzIHRoYXQgdGhlIHVzZXIgY2FuIHR1cm4gaXQKPiAgICAgICAgICAgICAgIG9uLCBhbmQgdHJ1 c3QgaXQgdG8gc2VsZWN0IGdvb2Qgb3B0aW9ucyB3aXRob3V0IHRoZSB1c2VyCj4gICAgICAgICAg ICAgICBuZWVkaW5nIHRvIGJlIGF3YXJlIG9mIHRoZSBvcHRpb25zIGJlaW5nIGFwcGxpZWQuIFRo aXMgaXMKPiAgICAgICAgICAgICAgIGEgZmFsbGFjeS4gRmVhdHVyZXMgc3VjaCBhcyBkaXJlY3Qg YmluZGluZ3MgcmVxdWlyZSB0aGUKPiAgICAgICAgICAgICAgIHVzZXIgdG8gZG8gc29tZSBhbmFs eXNpcyB0byBlbnN1cmUgdGhhdCB0aGUgcmVzdWx0aW5nCj4gICAgICAgICAgICAgICBwcm9ncmFt IHdpbGwgc3RpbGwgb3BlcmF0ZSBwcm9wZXJseS4KPgo+ICAgICAgICAgICAgIC0gQSB1c2VyIHdo byBpcyB3aWxsaW5nIHRvIGRvIHRoZSB3b3JrIHRvIGtub3cgd2hhdCAteiBiZXN0Cj4gICAgICAg ICAgICAgICBkb2VzIGlzIGNhcGFibGUgb2YgdHVybmluZyBvbiB0aG9zZSBmZWF0dXJlcyBkaXJl Y3RseSwKPiAgICAgICAgICAgICAgIGFuZCB0aGVyZWZvcmUgZ2FpbnMgbGl0dGxlIGJlbmVmaXQg ZnJvbSAteiBiZXN0Lgo+Cj4gICAgICAgICAgICAgLSBUaGUgaW50ZW50IGlzIHRoYXQgd2hlbiBh IHVzZXIgb3B0cyBpbnRvIC16IGJlc3QsIHRoYXQKPiAgICAgICAgICAgICAgIHRoZXkgdW5kZXJz dGFuZCB0aGF0IHogYmVzdCBpcyBzdWJqZWN0IHRvIHNvbWV0aW1lcwo+ICAgICAgICAgICAgICAg aW5jb21wYXRpYmxlIGV2b2x1dGlvbi4gRXhwZXJpZW5jZSB0ZWFjaGVzIHVzIHRoYXQKPiAgICAg ICAgICAgICAgIHRoaXMgd29uJ3Qgd29yay4gUGVvcGxlIHdpbGwgdXNlIHRoaXMgZmVhdHVyZSwg dGhlIG1lYW5pbmcKPiAgICAgICAgICAgICAgIG9mIC16IGJlc3Qgd2lsbCBjaGFuZ2UsIGNvZGUg dGhhdCB1c2VkIHRvIGJ1aWxkIHdpbGwgZmFpbCwKPiAgICAgICAgICAgICAgIGFuZCB0aGVuIHRo ZXJlIHdpbGwgYmUgY29tcGxhaW50cyBhbmQgZGVtYW5kcyB0byByZXRyYWN0Cj4gICAgICAgICAg ICAgICB0aGUgY2hhbmdlLiBXaGVuIChub3QgaWYpIHRoaXMgb2NjdXJzLCB3ZSB3aWxsIG9mIGNv dXJzZQo+ICAgICAgICAgICAgICAgZGVmZW5kIG91ciBhY3Rpb25zLCBhbmQgcG9pbnQgYXQgdGhl IGRpc2NsYWltZXIuIFdlJ2xsIHdpbgo+ICAgICAgICAgICAgICAgc29tZSBvZiB0aG9zZSBkZWJh dGVzLCBhbmQgbG9zZSBvdGhlcnMuIFVsdGltYXRlbHksIHdlJ2xsCj4gICAgICAgICAgICAgICBl bmQgdXAgd2l0aCAteiBiZXN0MiAoLXogYmV0dGVyKSwgb3Igb3RoZXIgY29tcHJvbWlzZXMsIGFu ZAo+ICAgICAgICAgICAgICAgb3VyIGdvYWwgb2Ygc2ltcGxpZnlpbmcgdGhlIHdvcmxkIHdpbGwg aGF2ZSBmYWlsZWQuCj4KPiAgICAgICAgICAgICAtIFRoZSAteiBiZXN0IGlkZWEgcm9sbHMgdXAg YSBzZXQgb2YgZmVhdHVyZXMgdGhhdAo+ICAgICAgICAgICAgICAgbWF5IG9yIG1heSBub3QgYmUg cmVsYXRlZCB0byBlYWNoIG90aGVyIGludG8gYSB1bml0Cj4gICAgICAgICAgICAgICB0aGF0IG11 c3QgYmUgdGFrZW4gd2hvbGVzYWxlLCBvciBub3QgYXQgYWxsLiBJdCBjb3VsZAo+ICAgICAgICAg ICAgICAgYmUgdGhhdCBvbmx5IGEgc3Vic2V0IG9mIHdoYXQgaXQgZG9lcyBpcyBjb21wYXRpYmxl Cj4gICAgICAgICAgICAgICB3aXRoIGEgZ2l2ZW4gYXBwbGljYXRpb24sIGluIHdoaWNoIGNhc2Ug dGhlIHVzZXIgaXMgZXhwZWN0ZWQKPiAgICAgICAgICAgICAgIHRvIGFiYW5kb24gLXogYmVzdCBh bmQgaW5zdGVhZCBzZXQgdGhlIG9wdGlvbnMgdGhhdCBhcHBseSB0bwo+ICAgICAgICAgICAgICAg dGhlaXIgYXBwbGljYXRpb24gZGlyZWN0bHkuIEluIGRvaW5nIHNvLCB0aGV5IGxvc2Ugb25lIG9m Cj4gICAgICAgICAgICAgICB0aGUgYmVuZWZpdHMgb2YgLXogYmVzdCwgdGhhdCBpZiB5b3UgdXNl IGl0LCBmdXR1cmUgdmVyc2lvbnMKPiAgICAgICAgICAgICAgIG9mIGxkIG1heSBjaG9vc2UgYSBk aWZmZXJlbnQgc2V0IG9mIG9wdGlvbnMsIGFuZCBhdXRvbWF0aWNhbGx5Cj4gICAgICAgICAgICAg ICBpbXByb3ZlIHRoZSBvYmplY3QgdGhyb3VnaCB0aGUgYWN0IG9mIHJlYnVpbGRpbmcgaXQuCj4K PkkgZHJhdyB0d28gY29uY2x1c2lvbnMgZnJvbSB0aGUgYWJvdmUgaGlzdG9yeToKPgo+ICAgICAo MSkgRm9yIGEgbGluay1lZGl0b3IsIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXMgdml0YWwuIElm Cj4gICAgICAgICBhIGdpdmVuIGNvbW1hbmQgbGluZSBsaW5rZWQgeW91ciBhcHBsaWNhdGlvbiAx MCB5ZWFycyBhZ28sCj4gICAgICAgICB5b3UgaGF2ZSBldmVyeSByZWFzb24gdG8gZXhwZWN0IHRo YXQgaXQgd2lsbCBsaW5rIHRvZGF5LAo+ICAgICAgICAgYXNzdW1pbmcgdGhhdCB0aGUgbGlicmFy aWVzIHlvdSdyZSBsaW5raW5nIGFnYWluc3QgYXJlIHN0aWxsCj4gICAgICAgICBhdmFpbGFibGUg YW5kIGNvbXBhdGlibGUgd2l0aCB0aGVpciBwcmV2aW91cyBpbnRlcmZhY2VzLgo+Cj4gICAgICgy KSBGb3IgYW4gYXBwbGljYXRpb24gb2YgYW55IHNpemUgb3IgY29tcGxleGl0eSwgdGhlcmUgaXMg bm8KPiAgICAgICAgIHN1YnN0aXR1dGUgZm9yIHRoZSB3b3JrIGludm9sdmVkIGluIGV4YW1pbmlu ZyB0aGUgY29kZSBhbmQKPiAgICAgICAgIGRldGVybWluaW5nIHdoaWNoIGxpbmtlciBvcHRpb25z IGFwcGx5IGFuZCB3aGljaCBkbyBub3QuCj4gICAgICAgICBUaGVzZSBvcHRpb25zIGFyZSBsYXJn ZWx5IG9ydGhvZ29uYWwgdG8gZWFjaCBvdGhlciwgYW5kCj4gICAgICAgICB0aGVyZSBhcmUgcmVh c29uYWJsZSByZWFzb25zIG5vdCB0byB1c2UgYW55IG9yIGFsbCBvZiB0aGVtLAo+ICAgICAgICAg ZXZlbiBpbiBtb2Rlcm4gYXBwbGljYXRpb25zLiBJdCBpcyBhIG1pc3Rha2UgdG8gdGllIHRoZW0K PiAgICAgICAgIHRvZ2V0aGVyLgo+Cj5UaGUgaWRlYSBmb3IgLXogZ3VpZGFuY2UgY2FtZSBmcm9t IGNvbnNpZGVyYXRpb24gb2YgdGhlc2UgcG9pbnRzLgo+QnkgZGVjb3VwbGluZyB0aGUgYWR2aWNl IGZyb20gdGhlIGFjdCBvZiB0YWtpbmcgdGhlIGFkdmljZSwgd2UgY2FuCj5yZXRhaW4gdGhlIGdv b2QgYXNwZWN0cyBvZiAteiBiZXN0IHdoaWxlIGF2b2lkaW5nIGl0cyBwaXRmYWxsczoKPgo+ICAg ICAtIC16IGd1aWRhbmNlIGdpdmVzIGFkdmljZSwgYnV0IHRoZSBkZWNpc2lvbiB0byB0YWtlIHRo YXQgYWR2aWNlCj4gICAgICAgcmVtYWlucyB3aXRoIHRoZSB1c2VyIHdobyBtdXN0IGV2YWx1YXRl IGl0cyBtZXJpdCBhbmQgbWFrZQo+ICAgICAgIGEgZGVjaXNpb24gdG8gdGFrZSBpdCBvciBub3Qu IEFzIHN1Y2gsIHdlIGFyZSBmcmVlIHRvIGNoYW5nZQo+ICAgICAgIHRoZSBzcGVjaWZpYyBndWlk YW5jZSBnaXZlbiBpbiBmdXR1cmUgcmVsZWFzZXMgb2YgbGQsIHdpdGhvdXQKPiAgICAgICBicmVh a2luZyBleGlzdGluZyBhcHBsaWNhdGlvbnMuIFRoZSBvbmx5IGZhbGxvdXQgZnJvbSB0aGlzIHdp bGwKPiAgICAgICBiZSBzb21lIG5ldyB3YXJuaW5ncyBpbiB0aGUgYnVpbGQgb3V0cHV0LCB3aGlj aCBjYW4gYmUgaWdub3JlZAo+ICAgICAgIG9yIGRlYWx0IHdpdGggYXQgdGhlIHVzZXIncyBjb252 ZW5pZW5jZS4KPgo+ICAgICAtIEl0IGRvZXMgbm90IGNvdXBsZSB0aGUgdmFyaW91cyBmZWF0dXJl cyBnaXZlbiBpbnRvIGEgc2luZ2xlCj4gICAgICAgInRha2UgaXQgb3IgbGVhdmUgaXQiIG9wdGlv biwgbWVhbmluZyB0aGF0IHRoZXJlIHdpbGwgYmUgbm8KPiAgICAgICBuZWVkIHRvIG9mZmVyICIt emd1aWRhbmNlMiIsIG9yIG90aGVyIHN1Y2ggdmFyaWFudHMgd2hlbgo+ICAgICAgIHRoaW5ncyBj aGFuZ2Ugb3ZlciB0aW1lLgo+Cj4gICAgIC0gVGhlIHVzZXIgaXMgZ2l2ZW4gdGhlIGZsZXhpYmls aXR5IHRvIGRpc2FibGUgc3BlY2lmaWMKPiAgICAgICBjYXRlZ29yaWVzIG9mIGd1aWRhbmNlIHdp dGhvdXQgbG9zaW5nIHRoZSBiZW5lZml0IG9mCj4gICAgICAgb3RoZXJzLCBpbmNsdWRpbmcgdGhv c2UgdGhhdCBtaWdodCBiZSBhZGRlZCB0byBmdXR1cmUKPiAgICAgICB2ZXJzaW9ucyBvZiB0aGUg c3lzdGVtLgo+Cj5BbHRob3VnaCAteiBmYXRhbC13YXJuaW5ncyBzdGFuZHMgb24gaXRzIG93biBh cyBhIHVzZWZ1bCBmZWF0dXJlLAo+aXQgaXMgb2YgcGFydGljdWxhciBpbnRlcmVzdCBpbiBjb21i aW5hdGlvbiB3aXRoIC16IGd1aWRhbmNlLgo+VXNlZCB0b2dldGhlciwgdGhlIGd1aWRhbmNlIHR1 cm5zIGZyb20gYWR2aWNlIHRvIGhhcmQgcmVxdWlyZW1lbnQ6IFRoZQo+dXNlciBtdXN0IGVpdGhl ciBtYWtlIHRoZSBzdWdnZXN0ZWQgY2hhbmdlLCBvciBleHBsaWNpdGx5IHJlamVjdAo+dGhlIGFk dmljZSwgaW4gb3JkZXIgdG8gZ2V0IGEgYnVpbGQuIFRoaXMgaXMgdmFsdWFibGUgaW4gZW52aXJv bm1lbnRzCj53aXRoIGhpZ2ggY29kaW5nIHN0YW5kYXJkcy4gSW4gYWRkaXRpb24sIGl0IGdhaW5z IHVzIGFuIGFkZGl0aW9uYWwKPnBvaW50IG9mIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgR05VIGxp bmstZWRpdG9yLgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPm9wZW5zb2xhcmlzLWFyYyBtYWlsaW5nIGxpc3QKPm9wZW5zb2xhcmlzLWFyY0BvcGVuc29s YXJpcy5vcmcK From Ali.Bahrami@Oracle.COM Wed Aug 4 21:35:20 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 o754ZK3g022943 for ; Wed, 4 Aug 2010 21:35:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o754ZKkh011546 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Aug 2010 21:35:20 -0700 (PDT) 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 <0L6N00401WQWGO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Aug 2010 21:35:20 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L6N000BIWQVIT90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Aug 2010 21:35:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o754ZJ9O002749 for ; Thu, 05 Aug 2010 04:35:19 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o74LShcq032671; Thu, 05 Aug 2010 04:35:15 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 467630581280982910; Wed, 04 Aug 2010 21:35:10 -0700 Received: from [10.7.250.18] (/10.7.250.18) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Aug 2010 21:35:06 -0700 Date: Wed, 04 Aug 2010 22:35:04 -0600 From: Ali Bahrami Subject: Re: PSARC 2010/312 Link-editor guidance In-reply-to: To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <4C5A3F78.6010601@Oracle.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 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C5A3F84.02F2:SCFMA4539814,ss=1,fgs=0 References: User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 16817 Garrett D'Amore wrote: > KzEsIGFuZCArMSB0byBhIGZ1dHVyZSBwcm9qZWN0IHRvIHVzZSB0aGVzZSBmbGFncyBpbiBPTi4g I've taken the liberty of pasting in the decoded version of this message below. - Ali ----------------------------------------------------------------- +1, and +1 to a future project to use these flags in ON. Thanks! - Garrett Ali Bahrami wrote: >I am sponsoring the following fasttrack for myself --- timeout 8/11/2010. >It adds three new options to the Solaris link-editor (ld). > >A copy of the original (ld.1.orig) and new (ld.1.new) ld manpage, as well >as diffs (ld.1.diffs) can be found in the case materials. > >Release Binding: Patch/Micro >-z guidance: Committed >-z fatal-warnings/--fatal-warnings Committed >-z nofatal-warnings/--no-fatal-warnings Committed > >-------------------------------------------------------------------------- >The new options are: > > -z guidance > > The link-editor has many options that are highly > recommended, but which are not on by default. When > the user enables the -z guidance feature, ld will issue > "guidance" warning (non-fatal) messages to recommend > options or changes that will result in a better object. > > > -z fatal-warnings, --fatal-warnings > > ld warnings are advisory, in that the link-editor continues > on to build the output object. If -z fatal-warnings is set, > warnings are treated as fatal conditions --- the output object > is not built, and a non-zero exit status is returned. This > feature is useful for building code that is held to very > high standards (such as the core Solaris OS/net consolidation), > since it will prevent inadvertent errors from slipping past > developers. It should be noted that this includes the warnings > issued by -z guidance. > > --fatal-warnings is the name used by the GNU ld for their version of > this feature. We will accept it as an alias for -z fatal-warnings. > > > -z nofatal-warnings, --no-fatal-warnings > > Undo the effect of -z fatal-warnings, and revert to non-fatal > warnings. This is the default, and so should be rarely needed, > but is useful in the context of the LD_OPTIONS environment > variable to override the use -f -z fatal-warnings from within > a Makefile: > > % LD_OPTIONS=-D-znofatal-warnings make > > --no-fatal-warnings is the name used by GNU ld for their version of > this feature. We will accept it as an alias for -z nofatal-warnings. > >I have successfully built the OS/net with -z guidance, and -z fatal-warnings >turned on. I was able to get a completely clean build with only a modest >set of changes (167 lines changed: 54 ins; 46 del; 67 mod). This reflects the >fact that we already do extensive checking of the objects in the OS/net >(via check_rtime). In general, the changes fall into the following categories: > > - Suppress guidance in known cases where the flagged behavior > needs to be retained. > > - Some applications pull in dependencies they do not directly require > for the benefit of plugins they later load, and the dependencies for > those plugins are not completely specified. Correcting the plugin > dependencies allows these extras to be dropped. > >Although not part of this case, I expect to integrate these changes >in a future project, and to apply -z guidance and -z fatal-warnings to >the OS/net by default. This should make it easier for developers to spot >difficulties earlier in the coding process. > >-------------------------------------------------------------------------- >Example: > >The following example demonstrates how the guidance feature >is intended to work. We will build a shared object that >has a variety of shortcomings: > > - Does not specify all it's dependencies > - Specifies dependencies it does not use > - Does not use direct bindings > - Uses a version 1 mapfile > - Contains relocations to the readonly allocable text (not PIC) > >This scenario is sadly very common --- many shared objects >have one or more of these issues. > > % cat hello.c > #include > #include > > void > hello(void) > { > printf("hello user %d\n", getpid()); > } > > % cat mapfile.v1 > # This version 1 mapfile will trigger a guidance message > > % cc -c hello.c > % ld -o hello.so -G -M mapfile.v1 hello.o -lelf > >As you can see, the operation completes without error, resulting >in a usable object. However, turning on guidance reveals a number >of things that could be better: > > ld -o hello.so -G -M mapfile.v1 hello.o -lelf -zguidance > ld: guidance: version 2 mapfile syntax recommended: mapfile.v1 > ld: guidance: -z lazyload option recommended before first dependency > ld: guidance: -B direct or -z direct option recommended before > first dependency > Undefined first referenced > symbol in file > getpid hello.o (symbol belongs to implicit > dependency /lib/libc.so.1) > printf hello.o (symbol belongs to implicit > dependency /lib/libc.so.1) > ld: warning: symbol referencing errors > ld: guidance: -z defs option recommended for shared objects > ld: guidance: removal of unused dependency recommended: libelf.so.1 > warning: Text relocation remains referenced > against symbol offset in file > .rodata1 (section) 0xa hello.o > getpid 0x4 hello.o > printf 0xf hello.o > ld: guidance: position independent (PIC) code recommended for shared objects > ld: guidance: see ld(1) -z guidance for more information > >Given the explicit advice in the above guidance messages, it is >relatively easy to modify the example to do the right things: > > % cat mapfile.v2 > # This version 2 mapfile will not trigger a guidance message > $mapfile_version 2 > > % cc -c -Kpic hello.c > % ld -o hello.so -G -Bdirect -M mapfile.v2 hello.o -lc -zguidance > >Although unlikely, one might imagine a scenario in which it was desired >to use non-PIC code, and accept the price of performing relocations at >runtime on the readonly allocable text segment: > > % cc -c hello.c > % ld -o hello.so -G -Bdirect -M mapfile.v2 hello.o -lc -zguidance > warning: Text relocation remains referenced > against symbol offset in file > .rodata1 (section) 0xa hello.o > getpid 0x4 hello.o > printf 0xf hello.o > ld: guidance: position independent (PIC) code recommended for shared objects > ld: guidance: see ld(1) -z guidance for more information > >It is easy to disable that specific guidance warning without losing the >overall benefit from allowing the remainder of the guidance feature to >operate: > > % ld -o hello.so -G -Bdirect -M mapfile.v2 hello.o -lc -zguidance=notext > > > > >-------------------------------------------------------------------------- >Rationale: > >The information that follows below is not strictly part of this >case, but provides background information that may prove useful >to the reader in understanding the evolution in thinking and design >that led to the implementation of -z guidance and -z fatal-warnings >in their current form. > > The Solaris link-editor is one of the older Unix commands. Over >the years, applications have grown in size and complexity, and the ELF >system has evolved to provide them with tools needed to manage their >growing requirements. Features such as lazy loading, and direct bindings >have been added. In an ideal world, many of these options would be defaults, >with rarely used options that allow the user to turn them off. However, the >reality is exactly the reverse: For backward compatibility, these features >are all options that must be explicitly turned on by the user. This has >led to a situation in which most applications do not take advantage of >the many improvements that have been made in linking over the last 20 >years. If their code seems to link and run without issue, what motivation >does a developer have to read a complex manpage, absorb the information >provided, choose the features that matter for their application, and apply >them? Experience shows that only the most motivated and diligent programmers >will make that effort. We would like to do something to make it easier >for everyone else. > >There have been many conversations over the years regarding this issue, >and how to address it. They break down along the following lines: > > Change ld defaults > Since the world would be a better place if these ld features were > defaults, the ls command could simply be changed to make them so. > > This idea is simple, elegant, and impossible. Doing so would > break a large number of existing applications, including those of > ISVs, big customers, a plethora of existing open source packages. > In each case, the owner of that code may choose to follow our lead > and fix their code, or they may view it as an invitation to reconsider > their commitment to our platform. Backward compatibility, and our > installed base of working software, is one of our greatest assets, > and not something to be lightly put at risk. Breaking backward > compatibility at this level of the system is likely to do more > harm than good. > > New link-editor > One might create a new linker command, not called 'ld', leaving the > old command as it is. The new one could use the same code as 'ld', > but would offer only modern options, with the proper defaults for > features such as direct binding. > > The resulting link-editor would be a pleasure to use. However, > the approach is doomed to niche status. There is a vast pile > of exiting code in the world built around the 'ld' command, that > reaches back to the 1970's. ld use is embedded in large and unknown > numbers of makefiles, and is used by name by compilers that > execute it. A Unix link-editor that is not named 'ld' will not find > a majority audience no matter how good it might be. > > Finally, a new linker command will eventually cease to be > new, and will accumulate its own burden of backward compatibility > issues. > > An option to make 'ld' do the right things automatically > > This line of reasoning is best summarized by a CR filed > in 2005, entitled > > 6239804 make it easier for ld(1) to do what's best > > The idea is to have a '-z best' option that unchains ld from > its backward compatibility commitment, and allows it to turn > on the "best" set of features, as determined by the authors > of 'ld'. The specific set of features enabled by -z best would > be subject to change over time, as requirements change. > > This idea is more realistic than the other two, but has not been > implemented to date because it has some significant issues. > > - The -z best proposal assumes that the user can turn it > on, and trust it to select good options without the user > needing to be aware of the options being applied. This is > a fallacy. Features such as direct bindings require the > user to do some analysis to ensure that the resulting > program will still operate properly. > > - A user who is willing to do the work to know what -z best > does is capable of turning on those features directly, > and therefore gains little benefit from -z best. > > - The intent is that when a user opts into -z best, that > they understand that z best is subject to sometimes > incompatible evolution. Experience teaches us that > this won't work. People will use this feature, the meaning > of -z best will change, code that used to build will fail, > and then there will be complaints and demands to retract > the change. When (not if) this occurs, we will of course > defend our actions, and point at the disclaimer. We'll win > some of those debates, and lose others. Ultimately, we'll > end up with -z best2 (-z better), or other compromises, and > our goal of simplifying the world will have failed. > > - The -z best idea rolls up a set of features that > may or may not be related to each other into a unit > that must be taken wholesale, or not at all. It could > be that only a subset of what it does is compatible > with a given application, in which case the user is expected > to abandon -z best and instead set the options that apply to > their application directly. In doing so, they lose one of > the benefits of -z best, that if you use it, future versions > of ld may choose a different set of options, and automatically > improve the object through the act of rebuilding it. > >I draw two conclusions from the above history: > > (1) For a link-editor, backward compatibility is vital. If > a given command line linked your application 10 years ago, > you have every reason to expect that it will link today, > assuming that the libraries you're linking against are still > available and compatible with their previous interfaces. > > (2) For an application of any size or complexity, there is no > substitute for the work involved in examining the code and > determining which linker options apply and which do not. > These options are largely orthogonal to each other, and > there are reasonable reasons not to use any or all of them, > even in modern applications. It is a mistake to tie them > together. > >The idea for -z guidance came from consideration of these points. >By decoupling the advice from the act of taking the advice, we can >retain the good aspects of -z best while avoiding its pitfalls: > > - -z guidance gives advice, but the decision to take that advice > remains with the user who must evaluate its merit and make > a decision to take it or not. As such, we are free to change > the specific guidance given in future releases of ld, without > breaking existing applications. The only fallout from this will > be some new warnings in the build output, which can be ignored > or dealt with at the user's convenience. > > - It does not couple the various features given into a single > "take it or leave it" option, meaning that there will be no > need to offer "-zguidance2", or other such variants when > things change over time. > > - The user is given the flexibility to disable specific > categories of guidance without losing the benefit of > others, including those that might be added to future > versions of the system. > >Although -z fatal-warnings stands on its own as a useful feature, >it is of particular interest in combination with -z guidance. >Used together, the guidance turns from advice to hard requirement: The >user must either make the suggested change, or explicitly reject >the advice, in order to get a build. This is valuable in environments >with high coding standards. In addition, it gains us an additional >point of compatibility with the GNU link-editor. >_______________________________________________ >opensolaris-arc mailing list >opensolaris-arc@opensolaris.org From Darren.Moffat@oracle.com Mon Aug 9 02:09:21 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 o7999LmR027348 for ; Mon, 9 Aug 2010 02:09:21 -0700 (PDT) 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 o7999Kt6010448 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 9 Aug 2010 04:09:21 -0500 (CDT) 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 <0L6V00F0BO3KCH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Aug 2010 02:09:20 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L6V00A0TO3KXA90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Aug 2010 02:09:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o7999JRb023303 for ; Mon, 09 Aug 2010 09:09:19 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o790fJ3D031130 for ; Mon, 09 Aug 2010 09:09:19 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 498212751281344939; Mon, 09 Aug 2010 02:08:59 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 02:08:58 -0700 Date: Mon, 09 Aug 2010 10:08:56 +0100 From: Darren J Moffat Subject: Re: PSARC 2010/312 Link-editor guidance In-reply-to: <4C59F590.70802@Oracle.COM> To: Ali Bahrami Cc: PSARC-ext@sun.com Message-id: <4C5FC5A8.90202@Oracle.COM> Organization: Oracle Solaris Security 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: <4C59F590.70802@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.4 Status: RO Content-Length: 108 Well presented rationale and the interface looks good. This gets my +1 as specified. -- Darren J Moffat From Ali.Bahrami@Oracle.COM Wed Aug 11 09:59:40 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 o7BGxeYJ022665 for ; Wed, 11 Aug 2010 09:59:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o7BGxdBc002712 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Aug 2010 11:59:40 -0500 (CDT) 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 <0L6Z00H03Z7FH700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Aug 2010 09:59:39 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L6Z0074BZ7EKT20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Aug 2010 09:59:39 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o7BGxcYX015877 for ; Wed, 11 Aug 2010 16:59:38 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7BGxaBQ021963 for ; Wed, 11 Aug 2010 16:59:36 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 487311351281545922; Wed, 11 Aug 2010 09:58:42 -0700 Received: from [172.20.25.67] (/10.85.25.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Aug 2010 09:58:42 -0700 Date: Wed, 11 Aug 2010 10:56:04 -0600 From: Ali Bahrami Subject: Re: PSARC 2010/312 Link-editor guidance In-reply-to: <4C59F590.70802@Oracle.COM> To: PSARC-ext@sun.com Message-id: <4C62D624.2010801@Oracle.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: <4C59F590.70802@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100719 Lightning/1.0b2 Thunderbird/3.1 Status: RO Content-Length: 156 There is no PSARC meeting scheduled today. As this case times out today and has received the required +1s, I have marked it as closed and approved. - Ali