From Rod.Evans@sun.com Mon Feb 25 15:37:34 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1PNbYeW002722 for ; Mon, 25 Feb 2008 15:37:34 -0800 (PST) Received: from Macintosh-2.local (punchin-rie.SFBay.Sun.COM [10.7.251.250]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1PNbYfl000110 for ; Mon, 25 Feb 2008 15:37:34 -0800 (PST) Message-ID: <47C3513E.1010902@sun.com> Date: Mon, 25 Feb 2008 15:37:34 -0800 From: Rod Evans User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: psarc-ext@sac.sfbay.sun.com Subject: 2008/148: new ldd(1) -p option Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3157 I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. ------------------------------------------------------------------------ 6357282 describes an enhancement to ldd(1), that would allow ldd to suppress relocation errors against or symbols. Shared objects are often built that refer to call-back interfaces. These are interfaces that are expected to be supplied by one of the objects callers. If the caller is unknown, or a dynamic executable, then the shared object can not be built with a dependency that will satisfy these call-back references. Using ldd(1) to process relocations will result in error diagnostics for any call-back references, as ldd(1) can not locate the necessary symbols: % ldd -r /usr/lib/mdb/proc/eft.so symbol not found: mdb_zalloc (/usr/lib/mdb/proc/eft.so) symbol not found: mdb_free (/usr/lib/mdb/proc/eft.so) symbol not found: mdb_vread (/usr/lib/mdb/proc/eft.so) ...... We've been able to use -zdefs with objects that have external call-backs by defining a mapfile with EXTERN or PARENT symbol definitions. These keywords translate to tags within the Syminfo section. The PARENT keyword is even used by ld.so.1 to process a correct direct binding to a parent. However, presently ldd(1) does not recognize these Syminfo tags, and still shows that the object has undefined references. The OSNet nightly build script check_rtime(1) is cluttered with a number of exceptions to exclude ldd(1) processing for objects that have external references. ------------------------------------------------------------------------ This ARC case adds a new -p option to ldd(1): A shared object can make reference to symbols that are expected to be supplied by the caller of the shared object. By default, such external references appear unresolved when using the -d or -r options. These references can be expli- citly classified when the shared object is created, as available from a parent, or simply as being external. See the -M mapfile option of ld(1), and the PARENT and EXTERN symbol definition keywords. Unresolved parent and external references can be silenced with the following option. -p Suppress unresolved symbol errors to explicit parent and external references. Thus, an ldd(1) that used to report an error can be silenced. For example, eft.so can be built with: % cat mapfile-extern { global: mdb_zalloc = EXTERN; mdb_free = EXTERN; mdb_vread = EXTERN; ... }; A standard ldd(1) will complain about unresolved references, however these errors can be supressed with -p % ldd -pr /usr/lib/mdb/proc/eft.so libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 ------------------------------------------------------------------------ Release Binding: Patch/Micro ldd -p option Committed -- Rod From sacadmin Mon Feb 25 15:33:13 2008 Received: from chaz.sfbay.sun.com (chaz [129.146.228.120]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1PNXDuH002646; Mon, 25 Feb 2008 15:33:13 -0800 (PST) Received: from chaz.sfbay.sun.com (localhost [127.0.0.1]) by chaz.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1PNWAFI000340; Mon, 25 Feb 2008 15:32:10 -0800 (PST) Received: (from rie@localhost) by chaz.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1PNWAgA000338; Mon, 25 Feb 2008 15:32:10 -0800 (PST) Date: Mon, 25 Feb 2008 15:32:10 -0800 (PST) From: Rod Evans Message-Id: <200802252332.m1PNWAgA000338@chaz.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: new ldd(1) -p option [PSARC/2008/148 Self Review] Status: RO Content-Length: 557 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: new ldd(1) -p option 1.2. Name of Document Author/Supplier: Author: Rod Evans 1.3 Date of This Document: 25 February, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OSNet 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Tue Feb 26 06:19:32 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QEJVPa028165 for ; Tue, 26 Feb 2008 06:19:32 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1QEJVMU024445; Tue, 26 Feb 2008 09:19:31 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1QEJV0g024442; Tue, 26 Feb 2008 09:19:31 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18372.8179.374824.478725@gargle.gargle.HOWL> Date: Tue, 26 Feb 2008 09:19:31 -0500 From: James Carlson To: Rod Evans Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: 2008/148: new ldd(1) -p option In-Reply-To: <47C3513E.1010902@sun.com> References: <47C3513E.1010902@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 726 Rod Evans writes: > % cat mapfile-extern > { > global: > mdb_zalloc = EXTERN; > mdb_free = EXTERN; > mdb_vread = EXTERN; > ... > }; If the symbols have been explicitly classed such that they're supposed to be resolved by the parent, then why should ldd complain about them in the first place? Why is "-p" needed, rather than just making that behavior the default? Isn't the "EXTERN" tag enough information? -- James Carlson, Solaris Networking Sun Microsystems / 35 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 Tue Feb 26 08:27:49 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QGRnrE001342 for ; Tue, 26 Feb 2008 08:27:49 -0800 (PST) Received: from Macintosh-2.local (punchin-rie.SFBay.Sun.COM [10.7.251.250]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1QGRnsd001207; Tue, 26 Feb 2008 08:27:49 -0800 (PST) Message-ID: <47C43E04.7000902@sun.com> Date: Tue, 26 Feb 2008 08:27:48 -0800 From: Rod Evans User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: James Carlson CC: psarc-ext@sac.sfbay.sun.com, Ali Bahrami Subject: Re: 2008/148: new ldd(1) -p option References: <47C3513E.1010902@sun.com> <18372.8179.374824.478725@gargle.gargle.HOWL> In-Reply-To: <18372.8179.374824.478725@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1164 James Carlson wrote: > Rod Evans writes: >> % cat mapfile-extern >> { >> global: >> mdb_zalloc = EXTERN; >> mdb_free = EXTERN; >> mdb_vread = EXTERN; >> ... >> }; > > If the symbols have been explicitly classed such that they're supposed > to be resolved by the parent, then why should ldd complain about them > in the first place? > > Why is "-p" needed, rather than just making that behavior the default? > Isn't the "EXTERN" tag enough information? You're not the first to make this observation :-) Yes, the new ldd(1) functionality could be implemented as the default behavior, and thus error messages that used to occur would magically disappear. As usual, I was concerned that any change in existing behavior might be noticed, and perhaps unappreciated by one or two. And thus I also had the fear that someone might ask for a new option (-p :-) to re-expose the symbols that aren't explicitly defined by their present dependencies, but were expected to be found somewhere from the objects callers. Hence my direction - but I could be easily swayed. -- Rod From carlsonj@phorcys.east.sun.com Tue Feb 26 08:46:46 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QGkjgK002026 for ; Tue, 26 Feb 2008 08:46:46 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1QGkjcJ025288; Tue, 26 Feb 2008 11:46:45 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1QGkjR6025285; Tue, 26 Feb 2008 11:46:45 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18372.17013.494903.794528@gargle.gargle.HOWL> Date: Tue, 26 Feb 2008 11:46:45 -0500 From: James Carlson To: Rod Evans Cc: psarc-ext@sac.sfbay.sun.com, Ali Bahrami Subject: Re: 2008/148: new ldd(1) -p option In-Reply-To: <47C43E04.7000902@sun.com> References: <47C3513E.1010902@sun.com> <18372.8179.374824.478725@gargle.gargle.HOWL> <47C43E04.7000902@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2107 Rod Evans writes: > James Carlson wrote: > > If the symbols have been explicitly classed such that they're supposed > > to be resolved by the parent, then why should ldd complain about them > > in the first place? > > > > Why is "-p" needed, rather than just making that behavior the default? > > Isn't the "EXTERN" tag enough information? > > You're not the first to make this observation :-) The first version of that message I drafted started with "this may be a dumb question, but ..." -- so it's good to hear I at least have company. ;-} > Yes, the new ldd(1) functionality could be implemented as > the default behavior, and thus error messages that used to > occur would magically disappear. As usual, I was concerned > that any change in existing behavior might be noticed, and > perhaps unappreciated by one or two. The change in behavior, though, is accompanied by a change in the source code of the application. In other words, ldd(1) would still do exactly the same thing on the same set of traditional bits. It would just gain new functionality (not complaining as much) when the application writer uses the 'EXTERN' or 'PARENT' symbol, something I doubt is very common, and is in any event quite intentional. > And thus I also had the fear that someone might ask for a > new option (-p :-) to re-expose the symbols that aren't > explicitly defined by their present dependencies, but were > expected to be found somewhere from the objects callers. > > Hence my direction - but I could be easily swayed. The new functionality seems completely in keeping with the original intent of those mapfile keywords, so I don't see a reason to be concerned about the change. (I'd suggest reverse logic, if anything: a way to restore the bogus errors for those who simply must see them. But I doubt that's really required, and there are probably better ways to do it.) -- James Carlson, Solaris Networking Sun Microsystems / 35 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 Sun Mar 2 22:25:00 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m236P0GL018761 for ; Sun, 2 Mar 2008 22:25:00 -0800 (PST) Received: from Macintosh-2.local (punchin-client-10-7-250-52.SFBay.Sun.COM [10.7.250.52]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m236P0k8421925; Sun, 2 Mar 2008 22:25:00 -0800 (PST) Message-ID: <47CB99BB.6010101@sun.com> Date: Sun, 02 Mar 2008 22:24:59 -0800 From: Rod Evans User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: James Carlson CC: psarc-ext@sac.sfbay.sun.com, Ali Bahrami Subject: Re: 2008/148: new ldd(1) -p option References: <47C3513E.1010902@sun.com> <18372.8179.374824.478725@gargle.gargle.HOWL> <47C43E04.7000902@sun.com> <18372.17013.494903.794528@gargle.gargle.HOWL> In-Reply-To: <18372.17013.494903.794528@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2566 James Carlson wrote: > > (I'd suggest reverse logic, if anything: a way to restore the bogus > errors for those who simply must see them. But I doubt that's really > required, and there are probably better ways to do it.) Sorry to take so long getting back ... fire drills else where. With your comments and others, I've indeed reversed the logic. ldd(1) will silence any unresolved PARENT or EXTERN errors when inspecting a shared object by default. Note, when inspecting an executable, which should have all relocations resolved for the process, *any* unresolved errors will still be displayed, just as they always have been, no matter whether PARENT or EXTERN directives have been used or not in any component of the process. But we're, still going to have a -p, and this will be used to expose any unresolved PARENT or EXTERN errors. The -p is now in keeping with the -w, which can be used to expose unresolved weak resolutions. ------------------------------------------------------------------------ Man page diffs: > ldd [-d | -r] [-c] [-e envar] [-f] [-i] [-L] [-l] [-p] [-s] > > .... > > Some unresolved symbol references are not reported by > default. These unresolved references can be reported with > the following options. These options can be combined with > either the -d option or the -r option. > > -p Expose any unresolved symbol errors to explicit parent > and external references. > > -w Expose any unresolved weak symbol references. > > A shared object can make reference to symbols that should be > supplied by the caller of the shared object. These refer- > ences can be explicitly classified when the shared object is > created, as being available from a parent, or simply as > being external. See the -M mapfile option of ld(1), and the > PARENT and EXTERN symbol definition keywords. When examining > a dynamic executable, a parent or external reference that > can not be resolved is flagged as an error. However by > default, when examining a shared object, a parent or exter- > nal reference that can not be resolved is not flagged as an > error. The -p option, when used with either the -d or -r > options, causes any unresolved parent or external reference > to be flagged as a relocation error. ------------------------------------------------------------------------ Release Binding: Patch/Micro ldd -p option Committed -- Rod From carlsonj@phorcys.east.sun.com Mon Mar 3 05:49:29 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m23DnSPP028094 for ; Mon, 3 Mar 2008 05:49:29 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m23DnSu4014231; Mon, 3 Mar 2008 08:49:28 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m23DnSP0014228; Mon, 3 Mar 2008 08:49:28 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18380.488.476323.198524@gargle.gargle.HOWL> Date: Mon, 3 Mar 2008 08:49:28 -0500 From: James Carlson To: Rod Evans Cc: psarc-ext@sac.sfbay.sun.com, Ali Bahrami Subject: Re: 2008/148: new ldd(1) -p option In-Reply-To: <47CB99BB.6010101@sun.com> References: <47C3513E.1010902@sun.com> <18372.8179.374824.478725@gargle.gargle.HOWL> <47C43E04.7000902@sun.com> <18372.17013.494903.794528@gargle.gargle.HOWL> <47CB99BB.6010101@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 494 Rod Evans writes: > But we're, still going to have a -p, and this will be used to > expose any unresolved PARENT or EXTERN errors. The -p is now in > keeping with the -w, which can be used to expose unresolved weak > resolutions. That sounds quite good to me; thanks! -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677