From sacadmin Wed Sep 5 08:32:02 2007 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 l85FW2cv017143; Wed, 5 Sep 2007 08:32:02 -0700 (PDT) Received: (from ab196087@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l85FW2r1017139; Wed, 5 Sep 2007 08:32:02 -0700 (PDT) Date: Wed, 5 Sep 2007 08:32:02 -0700 (PDT) From: Ali Bahrami Message-Id: <200709051532.l85FW2r1017139@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: elfedit [PSARC/2007/509 FastTrack timeout 9/12/2007] Status: RO Content-Length: 544 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: elfedit 1.2. Name of Document Author/Supplier: Author: Ali Bahrami 1.3 Date of This Document: 05 September, 2007 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@Sun.COM Wed Sep 5 09:02:53 2007 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 l85G2q7B019289 for ; Wed, 5 Sep 2007 09:02:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l85G03KP009231 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Sep 2007 00:00:05 +0800 (SGT) 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 <0JNW00J09KG39D00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Sep 2007 10:00:03 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNW00B19KG0XGB0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Sep 2007 10:00:00 -0600 (MDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l85G00XH026309 for ; Wed, 05 Sep 2007 16:00:00 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JNW00L01KE6RE00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Sep 2007 10:00:00 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JNW009JWKG0E8U1@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Sep 2007 10:00:00 -0600 (MDT) Date: Wed, 05 Sep 2007 09:57:46 -0600 From: Ali Bahrami Subject: PSARC/2007/509 elfedit Sender: Ali.Bahrami@Sun.COM To: psarc-ext@Sun.COM Message-id: <46DED1FA.6050707@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 12579 I am sponsoring the following fast track for myself - timeout 9/12/2007 ----------------------------------------------------------------------- Release Binding: Patch/Micro elfedit command line (shell) interface Committed elfedit internal command interface Committed output from simple and num output styles Committed Command line editing features (libtecla) Uncommitted Output from default (elfdump) output style Uncommitted Internal Module interface Private ----------------------------------------------------------------------- This case proposes to integrate a new command line level utility named elfedit into the Solaris ON consolidation. A hand formatted version of the manpage for the proposed utility can be found in the case materials. Much of the information in that document is not repeated here. elfedit is a tool for examining and modifying the ELF metadata that resides within ELF objects. It can be used as a batch mode tool from shell scripts, makefiles, etc, or as an interactive tool, for examining and exploring objects. Prior to elfedit, the sorts of modifications elfedit is designed to do required the user to write a program, usually in C using libelf. elfedit raises the programming level required to do this significantly. Many operations can be done using already written elfedit commands. For those that cannot, it is far easier to write an elfedit module to add the ability than it is to write a standalone program. elfedit is working software. It is installed and usable on my desktop machines. I invite anyone who is interested to log in (ssh) and try it: rtld.central (Ultra 20 --- amd64) ldd.central (Sunblade 2500 - sparcv9) The code may be examined in its current development gate: /net/linkers.central/export/ws/elfedit We envision elfedit being used to solve the following sorts of problems: [Small Fixups] To correct minor issues in a built file that cannot be easily rebuilt, or for which sources are not available. Probably the most notable such item is the ability to alter the runpath of objects built following the integration of PSARC 2007/127 Reserved space for editing ELF dynamic sections 6516118 Reserved space needed in ELF dynamic section and string table The ability to do this is a "Frequently Asked Question" for which there has previously been no good answer. This feature is expected to be used nearly as soon as it is available, to fix the runpaths of FOSS (free open source software) built for Solaris, which often has the wrong runpaths set. [Better Way To Support Specialized Rarely Used Features] As an avenue for delivering small features to change some object attributes without the need to add additional complex and specialized features to ld and ld.so.1. For example, we have had requests to allow a mechanism to ld that would allow the user to override the hardware capability bits that are set by the linker. Such a feature would be complex to document and burdens already complex commands with features that are rarely used. Such features are a natural fit to elfedit. (See the elfedit manpage for an example of modifying the hardware capabilities). [Linker Development] We sometimes work on linker features that require objects with new values or flag bits that the compilers do not yet generate. An elfedit utility will allow us to set arbitrary values for such items. [Linker Testing] Many bugs involve an object that is broken in some way. Once the bug is fixed, we need an object broken in that particular way for our test suite. There are several problems that arise: - Cataloging and archiving broken objects is time consuming and error prone. - Producing similarly broken objects for different platforms is not always possible. - As new platforms appear, we end up with coverage gaps where some platforms can do a given test and others cannot. elfedit gives us the ability to build a simple object, and then break it intentionally in a specific and controlled manner. Tests can then be self contained, requiring no external data, and applicable to all relevant platforms. elfedit's ability to extract specific bits of data from an object will also prove valuable in improving the test suite used by the linker group to test our work. Every elfedit module contains documentation for the commands it provides. This information is displayed using the built in help command, in a format that is based on that of Solaris manpages. The help strings in the standard elfedit modules supplied with Solaris are internationalized using the same i18n mechanisms employed by the rest of the linker software found under sgs. Hence, all elfedit modules supplied by Sun will have complete documentation, and will support the necessary language locales. As with any program that changes the contents of an ELF file, changes to an object by elfedit will invalidate any pre-existing elfsign signature. Assuming the changes are understood and acceptable to the signing authority, such objects will need to be signed after the edits are done. Modular Design And Extensibility -------------------------------- elfedit has a modular design, reflecting our own experience with dynamic linking, and influenced heavily by the design of mdb, the modular debugger. The elfedit program contains the code that handles the details of reading objects, executing commands to modify them, and saving the results. Very little of the code that performs the actual edits is found in elfedit itself. Rather, the commands exist in modules, which are sharable objects with a well defined elfedit-specific interface. elfedit loads needed modules on demand when a command from the module is executed. These modules are self contained, and include their own documentation in a standard format that elfedit can display using its help command. The module forms a namespace for the commands that it supplies. Each module delivers a set of commands, focused on related functionality. A command is specified by combining the module and command names with a colon (:) delimiter, with no intervening whitespace. For example, dyn:runpath refers to the runpath command provided by the dyn module. Module names must be unique. The command names within a given module are unique within that module, but the same command names can be used in more than one module. For example, most modules contain a command named 'dump', which is used to provide an elfedump-style view of the data. We have adopted the following general rules of thumb for naming modules and commands: - The module name reflects the part of the ELF format the module addresses (ehdr, phdr, shdr, ...) - Commands that directly access a field in an ELF structure are given the name of the field (e.g. ehdr:e_flags). - Commands that are higher level have a simple descriptive name that reflects their purpose (e.g. dyn:runpath). elfedit was designed from the very beginning with the idea that others outside of the Sun OS group should be able to write their own modules to extend its abilities. This is still the long term plan. However, we are planning to initially make the module interface private. This is a transitional move. We are satisfied with the user level functionality, and wish to integrate elfedit in order to make use of it and gain wider experience. Holding back the internal details for a period of time will allow necessary internal changes that result from this experience to be made more easily. We intend to file a case to open the internal module interface at a later time. Future Directions ----------------- The items discussed in this section are forward looking, and are not part of this case. However, it may be helpful to know what we consider to be the next steps: [Make Module Interface Public] As discussed in the previous section, our ultimate goal is to open the internal module interface and allow others to write their own modules. [Provide Missing Modules] The initial set of modules provided with elfedit cover the most commonly needed features, and represent a widely useful set of functionality. However, there are ELF data structures that we do not yet cover. Ultimately, a stock elfedit should have the ability to understand any part of a standard ELF object. My intent is to write and integrate additional modules to complete our coverage of the ELF standard as required to support other work, and/or as time allows. I would summarize these goals as (1) Let people write their own modules. (2) Make sure it is rarely necessary to do so. The overall goal is for elfedit as delivered to completely cover the ELF standard, leaving the need for custom modules to those working on new ELF extensions or other related activities. Files Delivered --------------- Once integrated, the source files for elfedit will be located with the rest of the linker software in: usr/src/cmd/sgs/elfedit On an installed system, this proposal adds elfedit executables under /usr/bin, and creates the new directory /usr/lib/elfedit for elfedit modules. On x86, the new files this case plans to integrate can be viewed with the command: # ls -alFR /usr/bin/elfedit /usr/bin/amd64/elfedit /usr/lib/elfedit -r-xr-xr-x 1 root bin 159448 Sep 3 14:32 /usr/bin/amd64/elfedit* -r-xr-xr-x 1 root bin 124916 Sep 3 14:32 /usr/bin/elfedit* /usr/lib/elfedit/: total 1016 drwxr-xr-x 3 root bin 512 Sep 4 14:00 ./ drwxr-xr-x 146 root bin 39424 Sep 4 14:00 ../ lrwxrwxrwx 1 root root 1 Sep 4 14:00 32 -> ./ lrwxrwxrwx 1 root root 5 Sep 4 14:00 64 -> amd64/ drwxr-xr-x 2 root bin 512 Sep 4 14:00 amd64/ -rwxr-xr-x 1 root bin 52484 Sep 3 14:32 cap.so* -rwxr-xr-x 1 root bin 80408 Sep 3 14:32 dyn.so* -rwxr-xr-x 1 root bin 97312 Sep 3 14:32 ehdr.so* -rwxr-xr-x 1 root bin 61416 Sep 3 14:32 phdr.so* -rwxr-xr-x 1 root bin 66152 Sep 3 14:32 shdr.so* -rwxr-xr-x 1 root bin 66364 Sep 3 14:32 sym.so* -rwxr-xr-x 1 root bin 49152 Sep 3 14:32 syminfo.so* /usr/lib/elfedit/amd64: total 1244 drwxr-xr-x 2 root bin 512 Sep 4 14:00 ./ drwxr-xr-x 3 root bin 512 Sep 4 14:00 ../ -rwxr-xr-x 1 root bin 70848 Sep 3 14:32 cap.so* -rwxr-xr-x 1 root bin 99624 Sep 3 14:32 dyn.so* -rwxr-xr-x 1 root bin 121192 Sep 3 14:32 ehdr.so* -rwxr-xr-x 1 root bin 79608 Sep 3 14:32 phdr.so* -rwxr-xr-x 1 root bin 80384 Sep 3 14:32 shdr.so* -rwxr-xr-x 1 root bin 88920 Sep 3 14:32 sym.so* -rwxr-xr-x 1 root bin 67424 Sep 3 14:32 syminfo.so* On sparc, the same files are installed, with "sparcv9" taking the place of "amd64": % ls -alFR /usr/bin/elfedit /usr/bin/sparcv9/elfedit /usr/lib/elfedit -r-xr-xr-x 1 root bin 139048 Sep 3 14:50 /usr/bin/elfedit* -r-xr-xr-x 1 root bin 147176 Sep 3 14:50 /usr/bin/sparcv9/elfedit* /usr/lib/elfedit/: total 1162 drwxr-xr-x 3 root bin 512 Sep 4 14:04 ./ drwxr-xr-x 146 root bin 39936 Sep 4 14:04 ../ lrwxrwxrwx 1 root root 1 Sep 4 14:04 32 -> ./ lrwxrwxrwx 1 root root 7 Sep 4 14:04 64 -> sparcv9/ -rwxr-xr-x 1 root bin 58660 Sep 3 14:51 cap.so* -rwxr-xr-x 1 root bin 91040 Sep 3 14:51 dyn.so* -rwxr-xr-x 1 root bin 107856 Sep 3 14:51 ehdr.so* -rwxr-xr-x 1 root bin 71632 Sep 3 14:51 phdr.so* -rwxr-xr-x 1 root bin 72184 Sep 3 14:51 shdr.so* drwxr-xr-x 2 root bin 512 Sep 4 14:04 sparcv9/ -rwxr-xr-x 1 root bin 75872 Sep 3 14:51 sym.so* -rwxr-xr-x 1 root bin 55464 Sep 3 14:51 syminfo.so* /usr/lib/elfedit/sparcv9: total 1200 drwxr-xr-x 2 root bin 512 Sep 4 14:04 ./ drwxr-xr-x 3 root bin 512 Sep 4 14:04 ../ -rwxr-xr-x 1 root bin 72840 Sep 3 14:52 cap.so* -rwxr-xr-x 1 root bin 98016 Sep 3 14:52 dyn.so* -rwxr-xr-x 1 root bin 115208 Sep 3 14:52 ehdr.so* -rwxr-xr-x 1 root bin 77568 Sep 3 14:52 phdr.so* -rwxr-xr-x 1 root bin 78080 Sep 3 14:52 shdr.so* -rwxr-xr-x 1 root bin 82160 Sep 3 14:52 sym.so* -rwxr-xr-x 1 root bin 69456 Sep 3 14:52 syminfo.so* From carlsonj@phorcys.east.sun.com Thu Sep 6 05:53:13 2007 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 l86CrD2O020093 for ; Thu, 6 Sep 2007 05:53:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l86CnscR000914; Thu, 6 Sep 2007 06:49:55 -0600 (MDT) 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 <0JNY00B5R6C23B00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 05:50:26 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNY007546C0CT20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 05:50:25 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l86CoOxQ130883; Thu, 06 Sep 2007 08:50:24 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l86CoOKs130880; Thu, 06 Sep 2007 08:50:24 -0400 (EDT) Date: Thu, 06 Sep 2007 08:50:24 -0400 From: James Carlson Subject: Re: PSARC/2007/509 elfedit In-reply-to: <46DED1FA.6050707@Sun.COM> To: Ali Bahrami Cc: psarc-ext@Sun.COM Message-id: <18143.63376.86865.869797@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46DED1FA.6050707@Sun.COM> Status: RO Content-Length: 2452 Ali Bahrami writes: > I am sponsoring the following fast track for myself - timeout 9/12/2007 Excellent new feature! Just two questions: > Internal Module interface Private What kind of "private" is that intended to be? "Project Private" would prevent others from contributing modules, which might be appropriate if you're not sure you're ready to open the interface within ON. "Consolidation Private" (the most likely case) would mean that others within ON can contribute modules without special review -- likely no ARC review at all, as it seems you aren't planning on submitting those interfaces for ARC review -- but not outside ON. Others are possible, but those seem like the two likely choices. > -r-xr-xr-x 1 root bin 159448 Sep 3 14:32 /usr/bin/amd64/elfedit* > -r-xr-xr-x 1 root bin 124916 Sep 3 14:32 /usr/bin/elfedit* Looking at the documentation, it seems that this utility is quite different from mdb in the way it handles bitted-ness. Mdb looks at the target program and then launches the correct version (32-bit or 64-bit) as needed. There's a tiny stub in /usr/bin that does this: % ls -l /usr/bin/mdb /usr/bin/i86/mdb /usr/bin/amd64/mdb -r-xr-xr-x 2 root bin 655528 Aug 28 12:57 /usr/bin/amd64/mdb -r-xr-xr-x 2 root bin 511468 Aug 28 12:57 /usr/bin/i86/mdb -r-xr-xr-x 70 root bin 9384 Aug 28 12:56 /usr/bin/mdb % Based on the man page, it seems that this program always runs as 64-bit if the platform supports 64-bit operation. It does so apparently without regard to the target type. Is that right? Why does it do that? Does it need to do that? The man page describes behavior that's almost like the existing isaexec feature. If that's what's needed here, then why doesn't it do that? (My guess is that this is borrowing design from elfdump rather than from mdb.) The documentation in the man page on this point seems strange: USAGE When supported by the system, elfedit runs as a 64-bit application, capable of processing files greater than or equal to 2 Gbytes (2^31 bytes). That's strange because you don't need to have a 64-bit application in order to process large files. That can't be the reason, can it? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Ali.Bahrami@Sun.COM Thu Sep 6 09:29:11 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l86GTBr6027215 for ; Thu, 6 Sep 2007 09:29:11 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l86GQOhd004188; Thu, 6 Sep 2007 09:26:25 -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 <0JNY0032FGC1S800@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 09:26:25 -0700 (PDT) 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 <0JNY007HLGBZD7E0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 09:26:23 -0700 (PDT) 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 l86GK086022153; Thu, 06 Sep 2007 16:26:23 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay43i.sun.com with ESMTP id BT-MMP-720377; Thu, 06 Sep 2007 16:26:23 +0000 (Z) Received: from relay43i.sun.com ([192.5.209.74] [192.5.209.74]) by mms49es.sun.com with ESMTP id BT-MMP-389129; Thu, 06 Sep 2007 16:26:22 +0000 (Z) Received: from emvision.com ([199.45.162.234] [199.45.162.234]) by relay4i.sun.com with ESMTP id BT-MMP-6830503; Thu, 06 Sep 2007 16:26:22 +0000 (Z) Received: from pod.emvision.com (pod.emvision.com [198.182.198.2]) by emvision.com (8.13.6/8.13.6) with ESMTP id l86GQKL9010754; Thu, 06 Sep 2007 10:26:21 -0600 (MDT) Date: Thu, 06 Sep 2007 10:26:33 -0600 From: Ali Bahrami Subject: Re: PSARC/2007/509 elfedit In-reply-to: <18143.63376.86865.869797@gargle.gargle.HOWL> To: James Carlson Cc: psarc-ext@Sun.COM Message-id: <46E02A39.7030900@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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (emvision.com [198.182.198.5]); Thu, 06 Sep 2007 10:26:21 -0600 (MDT) References: <46DED1FA.6050707@Sun.COM> <18143.63376.86865.869797@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 4368 James Carlson wrote: > Ali Bahrami writes: >> I am sponsoring the following fast track for myself - timeout 9/12/2007 > > Excellent new feature! Just two questions: > >> Internal Module interface Private > > What kind of "private" is that intended to be? "Project Private" > would prevent others from contributing modules, which might be > appropriate if you're not sure you're ready to open the interface > within ON. "Consolidation Private" (the most likely case) would mean > that others within ON can contribute modules without special review -- > likely no ARC review at all, as it seems you aren't planning on > submitting those interfaces for ARC review -- but not outside ON. > > Others are possible, but those seem like the two likely choices. > >> -r-xr-xr-x 1 root bin 159448 Sep 3 14:32 /usr/bin/amd64/elfedit* >> -r-xr-xr-x 1 root bin 124916 Sep 3 14:32 /usr/bin/elfedit* > > Looking at the documentation, it seems that this utility is quite > different from mdb in the way it handles bitted-ness. > > Mdb looks at the target program and then launches the correct version > (32-bit or 64-bit) as needed. There's a tiny stub in /usr/bin that > does this: > > % ls -l /usr/bin/mdb /usr/bin/i86/mdb /usr/bin/amd64/mdb > -r-xr-xr-x 2 root bin 655528 Aug 28 12:57 /usr/bin/amd64/mdb > -r-xr-xr-x 2 root bin 511468 Aug 28 12:57 /usr/bin/i86/mdb > -r-xr-xr-x 70 root bin 9384 Aug 28 12:56 /usr/bin/mdb > % > > Based on the man page, it seems that this program always runs as > 64-bit if the platform supports 64-bit operation. It does so > apparently without regard to the target type. Is that right? Why > does it do that? Does it need to do that? > > The man page describes behavior that's almost like the existing > isaexec feature. If that's what's needed here, then why doesn't it do > that? > > (My guess is that this is borrowing design from elfdump rather than > from mdb.) > > The documentation in the man page on this point seems strange: > > USAGE > When supported by the system, elfedit runs as a 64-bit > application, capable of processing files greater than > or equal to 2 Gbytes (2^31 bytes). > > That's strange because you don't need to have a 64-bit application in > order to process large files. That can't be the reason, can it? > Consolidation Private. The overall goal is to open it up, so having it open to ON is a reasonable first step. Anyone planning on using these interfaces is warned to expect a little churn, but I've implemented enough modules to have confidence that it is close to its final form. --- You are correct that elfedit will go 64-bit immediately on any system that can support it. This is like elfdump, and unlike mdb. Either version of elfedit (32 or 64-bit binary) is able to edit either form of ELF object (ELFCLASS32 or ELFCLASS64), so the reason to prefer 64-bit is for address space and large file support. It is true that a 32-bit program can process large files if built to be large file aware. However, to the best of my knowledge, none of the 32-bit linker tools are built that way. Instead, we always supply full 64-bit versions of the programs. Some large file aware programs can be written to process data in chunks that fit in memory, but the linker tools almost always want to map the entire object. This means that any linker tool that needs to be large file aware probably also needs large memory, which means it needs to be 64-bit. There is a scenario in which a 32-bit elfedit, editing a very large 32-bit object might fail due to address space limits, while a 64-bit elfedit would succeed. elfedit takes space in the process, on top of which libelf needs room for the object, which may be mapped or otherwise copied into memory. This is different than mdb, since mdb runs in its own address space, and does not increase the address space of its target. The mechanism used to handle this is in fact based on isaexec(). The linker tools all use a common internal function named conv_check_native() that examines the LD_NOEXEC_64 environment variable to decide what to do, and then uses isaexec() to do the work. elfedit is following this family pattern. My plan is to stay with the current implementation for this, but I am open to further discussion if you feel I've missed something. - Ali From carlsonj@phorcys.east.sun.com Thu Sep 6 09:41:41 2007 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 l86GfeGK028068 for ; Thu, 6 Sep 2007 09:41:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l86Gco0u001604; Thu, 6 Sep 2007 17:38:53 +0100 (BST) 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 <0JNY0041TGWRS400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 09:38:51 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNY004UZGWQ9610@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 09:38:50 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l86Gcn2w131888; Thu, 06 Sep 2007 12:38:49 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l86GcnZ2131885; Thu, 06 Sep 2007 12:38:49 -0400 (EDT) Date: Thu, 06 Sep 2007 12:38:49 -0400 From: James Carlson Subject: Re: PSARC/2007/509 elfedit In-reply-to: <46E02A39.7030900@Sun.COM> To: Ali Bahrami Cc: psarc-ext@sun.com Message-id: <18144.11545.836861.785089@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46DED1FA.6050707@Sun.COM> <18143.63376.86865.869797@gargle.gargle.HOWL> <46E02A39.7030900@Sun.COM> Status: RO Content-Length: 1500 Ali Bahrami writes: > Consolidation Private. The overall goal is to open it up, so having it > open to ON is a reasonable first step. Anyone planning on using these > interfaces is warned to expect a little churn, but I've implemented > enough modules to have confidence that it is close to its final form. OK; that sounds good. > You are correct that elfedit will go 64-bit immediately on any system > that can support it. This is like elfdump, and unlike mdb. Either version > of elfedit (32 or 64-bit binary) is able to edit either form of ELF object > (ELFCLASS32 or ELFCLASS64), so the reason to prefer 64-bit is for address > space and large file support. I see. > The mechanism used to handle this is in fact based on isaexec(). The > linker tools all use a common internal function named conv_check_native() > that examines the LD_NOEXEC_64 environment variable to decide what to > do, and then uses isaexec() to do the work. elfedit is following this > family pattern. I was actually referring to /usr/lib/isaexec, which is used as a hard-link for dozens of utilities with identical needs. I realize the answer for elfdump might just be "history," but why does elfedit follow elfdump's pattern? And why would a user want to (or need to) set LD_NOEXEC_64 ... ? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Ali.Bahrami@sun.com Thu Sep 6 10:16:31 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l86HGVSJ029715 for ; Thu, 6 Sep 2007 10:16:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l86HDhiV022893; Thu, 6 Sep 2007 10:13:45 -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 <0JNY00E0PIIVME00@brm-avmta-1.central.sun.com>; Thu, 06 Sep 2007 11:13:43 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNY00432IITJ5E0@brm-avmta-1.central.sun.com>; Thu, 06 Sep 2007 11:13:41 -0600 (MDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l86HDeM7009386; Thu, 06 Sep 2007 17:13:40 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay11i.sun.com with ESMTP id BT-MMP-52969; Thu, 06 Sep 2007 17:13:40 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.sun.com with ESMTP id BT-MMP-344011; Thu, 06 Sep 2007 17:13:40 +0000 (Z) Received: from emvision.com ([199.45.162.234] [199.45.162.234]) by relay1i.sun.com with ESMTP id BT-MMP-1151443; Thu, 06 Sep 2007 17:13:40 +0000 (Z) Received: from pod.emvision.com (pod.emvision.com [198.182.198.2]) by emvision.com (8.13.6/8.13.6) with ESMTP id l86HDdl2010851; Thu, 06 Sep 2007 11:13:39 -0600 (MDT) Date: Thu, 06 Sep 2007 11:13:50 -0600 From: Ali Bahrami Subject: Re: PSARC/2007/509 elfedit In-reply-to: <18144.11545.836861.785089@gargle.gargle.HOWL> To: James Carlson Cc: psarc-ext@sun.com Message-id: <46E0354E.1030501@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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (emvision.com [198.182.198.5]); Thu, 06 Sep 2007 11:13:39 -0600 (MDT) References: <46DED1FA.6050707@Sun.COM> <18143.63376.86865.869797@gargle.gargle.HOWL> <46E02A39.7030900@Sun.COM> <18144.11545.836861.785089@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 1471 James Carlson wrote: > Ali Bahrami writes: >> The mechanism used to handle this is in fact based on isaexec(). The >> linker tools all use a common internal function named conv_check_native() >> that examines the LD_NOEXEC_64 environment variable to decide what to >> do, and then uses isaexec() to do the work. elfedit is following this >> family pattern. > > I was actually referring to /usr/lib/isaexec, which is used as a > hard-link for dozens of utilities with identical needs. > > I realize the answer for elfdump might just be "history," but why does > elfedit follow elfdump's pattern? > > And why would a user want to (or need to) set LD_NOEXEC_64 ... ? > Sorry, I missed that you were talking about the wrapper rather than the function. I agree that there is not much value to the end user in setting LD_NOEXEC_64 for elfedit. However, someone writing an elfedit module might need to force the 32-bit version of their code to run for testing reasons. The ability to let the user do that is one reason not to use /usr/lib/isaexec, while following the "linker herd" is the other. The performance impact should be minimal --- the call to isaexec happens before the 32-bit elfedit does any work beyond argument processing, so the difference between what elfedit and /usr/lib/isaexec do is small. I just used cscope to find out who uses conv_check_native: crle, dump, elfdump, ld, mcs/strip, moe, nm, pvs It's a larger club than just elfdump. - Ali From carlsonj@phorcys.east.sun.com Thu Sep 6 10:26:37 2007 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 l86HQbeh029970 for ; Thu, 6 Sep 2007 10:26:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l86HNIoh043639; Thu, 6 Sep 2007 11:23:19 -0600 (MDT) 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 <0JNY0080PIZQDA00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 10:23:50 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNY007NFIZQWZ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 10:23:50 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l86HNoR6132267; Thu, 06 Sep 2007 13:23:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l86HNnCe132264; Thu, 06 Sep 2007 13:23:49 -0400 (EDT) Date: Thu, 06 Sep 2007 13:23:49 -0400 From: James Carlson Subject: Re: PSARC/2007/509 elfedit In-reply-to: <46E0354E.1030501@Sun.COM> To: Ali Bahrami Cc: psarc-ext@sun.com Message-id: <18144.14245.953620.293550@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46DED1FA.6050707@Sun.COM> <18143.63376.86865.869797@gargle.gargle.HOWL> <46E02A39.7030900@Sun.COM> <18144.11545.836861.785089@gargle.gargle.HOWL> <46E0354E.1030501@Sun.COM> Status: RO Content-Length: 1468 Ali Bahrami writes: > I agree that there is not much value to the end user in setting > LD_NOEXEC_64 for elfedit. However, someone writing an elfedit module might > need to force the 32-bit version of their code to run for testing reasons. > The ability to let the user do that is one reason not to use /usr/lib/isaexec, Actually, that's not a reason. If you're using the /usr/lib/isaexec trick, you don't need LD_NOEXEC_64 at all. The user can invoke /usr/bin/elfedit if he wants the system to choose, and can directly invoke /usr/bin/$ISA/elfedit if he wants to specify 32- or 64-bit operation exactly. > while following the "linker herd" is the other. That seems like the main reason. > The performance impact should be minimal --- the call to isaexec happens > before the 32-bit elfedit does any work beyond argument processing, so > the difference between what elfedit and /usr/lib/isaexec do is small. > > I just used cscope to find out who uses conv_check_native: > > crle, dump, elfdump, ld, mcs/strip, moe, nm, pvs > > It's a larger club than just elfdump. It wasn't a performance issue, but rather "another one of those things" issue. That said, I give. As long as you're comfortable in that crowd, I won't complain. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Rod.Evans@Sun.COM Thu Sep 6 11:01:25 2007 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 l86I1P4e001372 for ; Thu, 6 Sep 2007 11:01:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l86Hw229057702; Thu, 6 Sep 2007 11:58:06 -0600 (MDT) 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 <0JNY00B15KLQC500@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 10:58:38 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNY007FWKLPWZ50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 10:58:37 -0700 (PDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l86Hwb9i473910; Thu, 06 Sep 2007 10:58:37 -0700 (PDT) Date: Thu, 06 Sep 2007 10:55:42 -0700 From: Rod Evans Subject: Re: PSARC/2007/509 elfedit In-reply-to: <18144.14245.953620.293550@gargle.gargle.HOWL> To: James Carlson Cc: Ali Bahrami , psarc-ext@Sun.COM Reply-to: Rod.Evans@Sun.COM Message-id: <46E03F1E.1060105@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: <46DED1FA.6050707@Sun.COM> <18143.63376.86865.869797@gargle.gargle.HOWL> <46E02A39.7030900@Sun.COM> <18144.11545.836861.785089@gargle.gargle.HOWL> <46E0354E.1030501@Sun.COM> <18144.14245.953620.293550@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070703) Status: RO Content-Length: 1220 James Carlson wrote: >> while following the "linker herd" is the other. > > That seems like the main reason. As a historical note, when the 64-bit port originated, ld(1) followed the isaexec() model. But this broke the compilers. The compilers were 32-bit for a long time, and had facilities that would let sub-processes be timed (using /proc). When these facilities came across the automagic execution of a 64-bit ld(1) trouble ensued. We were forced to abandon isaexec() and invent our own model. We look at the first relocatable object on the command line, and if it is 32-bit we remain within the 32-bit ld(). If the object is 64-bit we kick off an isaexec like function to determine if the 64-bit ld exists, and if so run it. There are other tricks at play, as some customers wish to force the execution of the 64-bit ld (they exhaust the 32-bit address space even when building their enormous objects). Some customers wished to force the execution of a 32-bit ld claiming it was faster for their enormous objects. This is all wrapped up in conv_check_native() under sgs. And as we like to eat our own dog food, the various other sgs utilities we work on have adopted using the same routine. -- Rod. From carlsonj@phorcys.east.sun.com Thu Sep 6 11:15:43 2007 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 l86IFgYI001911 for ; Thu, 6 Sep 2007 11:15:43 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l86ICkEr029168; Thu, 6 Sep 2007 19:12:55 +0100 (BST) 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 <0JNY00K03L9IY700@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Sep 2007 11:12:54 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNY00IETL9I5A80@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Sep 2007 11:12:54 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l86ICsvp132643; Thu, 06 Sep 2007 14:12:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l86ICsRL132640; Thu, 06 Sep 2007 14:12:54 -0400 (EDT) Date: Thu, 06 Sep 2007 14:12:53 -0400 From: James Carlson Subject: Re: PSARC/2007/509 elfedit In-reply-to: <46E03F1E.1060105@sun.com> To: Rod.Evans@sun.com Cc: Ali Bahrami , psarc-ext@sun.com Message-id: <18144.17189.986249.463499@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46DED1FA.6050707@Sun.COM> <18143.63376.86865.869797@gargle.gargle.HOWL> <46E02A39.7030900@Sun.COM> <18144.11545.836861.785089@gargle.gargle.HOWL> <46E0354E.1030501@Sun.COM> <18144.14245.953620.293550@gargle.gargle.HOWL> <46E03F1E.1060105@sun.com> Status: RO Content-Length: 912 Rod Evans writes: > We were forced to abandon isaexec() and invent our own model. > We look at the first relocatable object on the command line, > and if it is 32-bit we remain within the 32-bit ld(). If the > object is 64-bit we kick off an isaexec like function to determine > if the 64-bit ld exists, and if so run it. I can understand that target-sensitive behavior. It's similar to what mdb does. That's explicitly _not_ what elfedit is doing here, at least according to the submitter. > This is all wrapped up in conv_check_native() under sgs. And as > we like to eat our own dog food, the various other sgs utilities > we work on have adopted using the same routine. OK ... -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Rod.Evans@sun.com Thu Sep 6 11:44:29 2007 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 l86IiT8r002847 for ; Thu, 6 Sep 2007 11:44:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l86IfAdb008654; Thu, 6 Sep 2007 12:41:11 -0600 (MDT) 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 <0JNY00F05MLH5Y00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 11:41:41 -0700 (PDT) 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 <0JNY007Q3MLGX4B0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 11:41:40 -0700 (PDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l86IfeRE485120; Thu, 06 Sep 2007 11:41:40 -0700 (PDT) Date: Thu, 06 Sep 2007 11:38:48 -0700 From: Rod Evans Subject: Re: PSARC/2007/509 elfedit In-reply-to: <18144.17189.986249.463499@gargle.gargle.HOWL> To: James Carlson Cc: Ali Bahrami , psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <46E04938.6000505@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: <46DED1FA.6050707@Sun.COM> <18143.63376.86865.869797@gargle.gargle.HOWL> <46E02A39.7030900@Sun.COM> <18144.11545.836861.785089@gargle.gargle.HOWL> <46E0354E.1030501@Sun.COM> <18144.14245.953620.293550@gargle.gargle.HOWL> <46E03F1E.1060105@sun.com> <18144.17189.986249.463499@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070703) Status: RO Content-Length: 899 James Carlson wrote: > Rod Evans writes: >> We were forced to abandon isaexec() and invent our own model. >> We look at the first relocatable object on the command line, >> and if it is 32-bit we remain within the 32-bit ld(). If the >> object is 64-bit we kick off an isaexec like function to determine >> if the 64-bit ld exists, and if so run it. > > I can understand that target-sensitive behavior. It's similar to what > mdb does. > > That's explicitly _not_ what elfedit is doing here, at least according > to the submitter. ld(1) is selective on when/how it calls conv_check_native() to provide the correct relocatable object class processing. Most other sgs utilities simply call conv_check_native() at startup, and thus get an isaexec effect. The LD_NOEXEC_64 is a freebie that's embedded in conv_check_native() - admittedly this was originally designed for ld(1)'s use. -- Rod. From Ali.Bahrami@sun.com Thu Sep 6 12:05:38 2007 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 l86J5bVW003535 for ; Thu, 6 Sep 2007 12:05:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l86J2oZ3007044 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 7 Sep 2007 03:02:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNY00M09NKQZG00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Sep 2007 12:02:50 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNY00IBWNKP5AE0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Sep 2007 12:02:49 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l86J2nhk004469 for ; Thu, 06 Sep 2007 19:02:49 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JNY00501NAD6I00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Sep 2007 13:02:49 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JNY00IHBNKPC9Q6@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Sep 2007 13:02:49 -0600 (MDT) Date: Thu, 06 Sep 2007 13:00:35 -0600 From: Ali Bahrami Subject: Re: PSARC/2007/509 elfedit In-reply-to: <18144.14245.953620.293550@gargle.gargle.HOWL> Sender: Ali.Bahrami@sun.com To: James Carlson Cc: psarc-ext@sun.com Message-id: <46E04E53.5010602@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46DED1FA.6050707@Sun.COM> <18143.63376.86865.869797@gargle.gargle.HOWL> <46E02A39.7030900@Sun.COM> <18144.11545.836861.785089@gargle.gargle.HOWL> <46E0354E.1030501@Sun.COM> <18144.14245.953620.293550@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1289 James Carlson wrote: > Ali Bahrami writes: >> I agree that there is not much value to the end user in setting >> LD_NOEXEC_64 for elfedit. However, someone writing an elfedit module might >> need to force the 32-bit version of their code to run for testing reasons. >> The ability to let the user do that is one reason not to use /usr/lib/isaexec, > > Actually, that's not a reason. > > If you're using the /usr/lib/isaexec trick, you don't need > LD_NOEXEC_64 at all. The user can invoke /usr/bin/elfedit if he wants > the system to choose, and can directly invoke /usr/bin/$ISA/elfedit > if he wants to specify 32- or 64-bit operation exactly. After I sent that message, I stepped out to get lunch, and almost immediately had an "oops" moment. You're right, the "real" 32-bit binary in /usr/bin/$ISA/elfedit is just sitting there waiting to be run directly, and this is hardly less obvious than setting LD_NOEXEC_64. >> while following the "linker herd" is the other. > > That seems like the main reason. Yes > It wasn't a performance issue, but rather "another one of those > things" issue. > > That said, I give. As long as you're comfortable in that crowd, I > won't complain. I'll discuss this further with Rod, and we'll decide which herd to follow. Thanks... - Ali