From Rod.Evans@sun.com Mon Mar 17 10:43:08 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2HHh8s6020549 for ; Mon, 17 Mar 2008 10:43:08 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2HHh3WC000403 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 Mar 2008 10:43:08 -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 <0JXV00A0DYJUWP00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Mar 2008 11:43:06 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXV00LV1YJT6I60@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Mar 2008 11:43:05 -0600 (MDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2HHh5k4125047 for ; Mon, 17 Mar 2008 10:43:05 -0700 (PDT) Date: Mon, 17 Mar 2008 10:41:49 -0700 From: Rod Evans Subject: 2008/198: elfwrap - wrap data in an ELF file To: psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <47DEAD5D.9080807@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 6592 -------------------------------------------------------------------------- I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. -------------------------------------------------------------------------- A request from the "ddi" folks (6675591), for a means of wrapping firmware updates into an object that can be easily loaded by a device driver, has triggered the creation of a new generic utility, elfwrap(1). The new elfwrap(1) man page says it all. Plus, an update to ddli_modopen(9f) provides a suitable cross reference. In keeping with the new cross-linker technology provided with 6671255 PSARC/2008/179, elfdump(1) uses the same -64 and -ztarget={sparc | x86} options as ld(1) to allow the creation of relocatable objects for each platform Solaris presently supports. -------------------------------------------------------------------------- User Commands elfwrap(1) NAME elfwrap - wrap data in an ELF file SYNOPSIS elfdump [-64] [-o relobj-file] [-z target=sparc | x86] data-file... DESCRIPTION The elfwrap utility creates an ELF relocatable object file from one or more data files. The relocatable object encapsu- lates each data file within an individual section, together with symbols that can be used to reference the section. The relocatable object is appropriate for inclusion with a sub- sequent link-edit. Users can reference the encapsulated data using the associated symbols. By default, a 32bit ELF relocatable object is created that is appropriate for the machine on which elfwrap is executed. The -64 option can be used to create a 64bit ELF relocatable object. The -z target option can be used to create a relo- catable object for a specific machine type. Note - Any data encapsulated with elfwrap must be in a for- mat appropriate for the destination target. By default, the relocatable object a.wrap.o is created. The -o option can be used to specify an alternative relocatable object name. The basename(1) of each data file is used to create various pieces of ELF information. For example, if the input data file is ISV/isv-data, the following ELF information is created within the relocatable object. An ELF section named .isv-data This section contains the entire contents of the input data file. An ELF symbol named isv-data_start This symbol reflects the starting address of the .isv- data section. An ELF symbol named isv-data_end This symbol reflects the address of the first location after the .isv-data section. OPTIONS The following options are supported: -64 Create a 64bit ELF relocatable object. -o relobj-file Produce a relocatable object that is named relobj-file. -z target=sparc | x86 Specifies the machine type for the output relocatable object. Supported targets are sparc and x86. The 32bit machine type for the specified target is used unless the -64 option is also present, in which case the corresponding 64bit machine type is used. By default, the relocatable object that is generated is 32bit for the machine one which elfwrap is executed. The following example encapsulates the system passwd file and the system group file within a relocatable object passgroup.o. example% elfwrap -o passgroup.o /etc/passwd /etc/group example% elfdump -s passgroup.o | egrep "passwd|group" [2] 0x00000000 0x00000000 SECT LOCL D 0 .passwd [3] 0x00000000 0x00000000 SECT LOCL D 0 .group [7] 0x00000000 0x000002f0 OBJT GLOB D 0 .passwd passwd_start [8] 0x000002f0 0x00000000 OBJT GLOB D 0 .passwd passwd_end [9] 0x00000000 0x00000121 OBJT GLOB D 0 .group group_start [10] 0x00000121 0x00000000 OBJT GLOB D 0 .group group_end example% strings -N.passwd passgroup.o | head -1 root:x:0:0:Super-User:/:/sbin/sh example% strings -N.group passgroup.o | head -1 root::0: This relocatable object can be referenced from the following user code. EXAMPLES example% cat main.c #include stdio.h> extern char passwd_start, passwd_end; void main() { char *pstart = passwd_start, *pend = passwd_end; char *str, *lstr; for (lstr = str = pstart; str pend; str++) { if ((*str == '0') (str != (pend - 1))) { (void) printf("%.*s", (++str - lstr), lstr); lstr = str; } } } example% cc -o main main.c passgroup.o example% ./main root:x:0:0:Super-User:/:/sbin/sh .... nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: FILES a.wrap.o The default relocatable object file created. -------------------------------------------------------------------------- Kernel Functions for Drivers ddi_modopen(9F) ...... 201c205,224 > Example 2: Dynamically Accessing a Kernel Module within a > Drive > > The following example shows driver code to dynamically load > into the kernel a module constructed via the elfwrap(1) > utility and containing firmware intended for download to a > device. The start and end pointers provide the addresses of > the beginning of the data and first byte beyond the data. > > ddi_modhandle_t modp; > char *data_startp, *data_endp; > size_t nbytes; > int rv; > > modp = ddi_modopen("firmware-rev1.2a", KRTLD_MODE_FIRST, ); > data_startp = (char *)ddi_modsym(modp, "fw-rev1.2a_start", ); > data_endp = (char *)ddi_modsym(modp, "fw-rev1.2a_end", ); > nbytes = data_endp - data_startp; > rv = ddi_modclose(modp); 203c226,227 < modload(1M), system(4), _fini(9E), _info(9E), _init(9E) --- > elfwrap(1), modload(1M), system(4), _fini(9E), _info(9E), > _init(9E) -------------------------------------------------------------------------- Release Binding: Patch/Micro elfwrap(1): Committed -- Rod. From sacadmin Mon Mar 17 10:41:37 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 m2HHfbxS020497; Mon, 17 Mar 2008 10:41:37 -0700 (PDT) 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 m2HHeLAw025959; Mon, 17 Mar 2008 10:40:21 -0700 (PDT) Received: (from rie@localhost) by chaz.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m2HHeLuI025957; Mon, 17 Mar 2008 10:40:21 -0700 (PDT) Date: Mon, 17 Mar 2008 10:40:21 -0700 (PDT) From: Rod Evans Message-Id: <200803171740.m2HHeLuI025957@chaz.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: elfwrap - wrap data in an ELF file [PSARC/2008/198 Self Review] Status: RO Content-Length: 568 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: elfwrap - wrap data in an ELF file 1.2. Name of Document Author/Supplier: Author: Rod Evans 1.3 Date of This Document: 17 March, 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 Darren.Moffat@sun.com Mon Mar 17 11:04:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2HI4KtN021192 for ; Mon, 17 Mar 2008 11:04:20 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2HI4Bjl016642 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 Mar 2008 18:04:19 GMT 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 <0JXV00F0RZJ6SX00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Mar 2008 11:04:18 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXV007ARZIZTW50@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Mar 2008 11:04:12 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2HI4B6u005184 for ; Mon, 17 Mar 2008 18:04:11 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXV00K01ZI29700@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Mar 2008 18:04:11 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXV00EY8ZIYN910@fe-emea-09.sun.com>; Mon, 17 Mar 2008 18:04:10 +0000 (GMT) Date: Mon, 17 Mar 2008 18:04:10 +0000 From: Darren J Moffat Subject: Re: 2008/198: elfwrap - wrap data in an ELF file In-reply-to: <47DEAD5D.9080807@sun.com> Sender: Darren.Moffat@sun.com To: Rod.Evans@sun.com Cc: psarc-ext@sun.com Message-id: <47DEB29A.8080408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47DEAD5D.9080807@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 1112 Rod Evans wrote: > -------------------------------------------------------------------------- > > I'm sponsoring the following case for myself. This case qualifies for > Architectural self-review, but I wish to record the following > information. > > -------------------------------------------------------------------------- > > A request from the "ddi" folks (6675591), for a means of wrapping firmware > updates into an object that can be easily loaded by a device driver, has > triggered the creation of a new generic utility, elfwrap(1). The new > elfwrap(1) man page says it all. Plus, an update to ddli_modopen(9f) > provides a suitable cross reference. This case seems to be somewhat related to "2008/151 Pluggable fwflash(1M). The relation I'm seeing is that they are both related to firmware updates. Are they related or are two different solutions being created to solve firmware updates ? If so why do we need two different things ? Now that aside I can see other (very hacky) uses for this and I "love" the example of wrapping /etc/passwd - that is pretty cute. -- Darren J Moffat From roland.mainz@nrubsig.org Mon Mar 17 11:20:58 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2HIKvR3021514 for ; Mon, 17 Mar 2008 11:20:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2HIKu8o022110; Mon, 17 Mar 2008 12:20:57 -0600 (MDT) 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 <0JXW00D3L0AVE100@brm-avmta-1.central.sun.com>; Mon, 17 Mar 2008 12:20:55 -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 <0JXW00LN70AT6HA0@brm-avmta-1.central.sun.com>; Mon, 17 Mar 2008 12:20:54 -0600 (MDT) Received: from relay17i.sun.com (ip127.net129179-4.block1.us.syntegra.com [129.179.4.127]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2HIKrAX029603; Mon, 17 Mar 2008 18:20:53 +0000 (GMT) Received: from mmp13es.sun.com ([160.41.209.23] [160.41.209.23]) by relay17i.sun.com with ESMTP id BT-MMP-249311; Mon, 17 Mar 2008 18:20:53 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.sun.com with ESMTP id BT-MMP-208561; Mon, 17 Mar 2008 18:20:53 +0000 (Z) Received: from mail-in-11.arcor-online.net ([151.189.21.51] [151.189.21.51]) by relay1i.sun.com with ESMTP id BT-MMP-2336990; Mon, 17 Mar 2008 18:20:52 +0000 (Z) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mail-in-11.arcor-online.net (Postfix) with ESMTP id DA72C20942A; Mon, 17 Mar 2008 19:20:50 +0100 (CET) Received: from mail-in-13.arcor-online.net (mail-in-13.arcor-online.net [151.189.21.53]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id C3CF76BD7D; Mon, 17 Mar 2008 19:20:50 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-059-008-061.pools.arcor-ip.net [84.59.8.61]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id 5BB6823D1E3; Mon, 17 Mar 2008 19:20:50 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m2HIKlfR007359; Mon, 17 Mar 2008 19:20:48 +0100 (CET) Date: Mon, 17 Mar 2008 19:20:47 +0100 From: Roland Mainz Subject: Re: 2008/198: elfwrap - wrap data in an ELF file Sender: gisburn@jupiterb48.nrubsig.org To: Rod.Evans@sun.com Cc: psarc-ext@sun.com Message-id: <47DEB67F.937EC7B6@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/6276/Mon Mar 17 17:06:31 2008 on mail-in-13.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=-2.6/5.0, scanned in 0.091sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47DEAD5D.9080807@sun.com> Status: RO Content-Length: 1105 Rod Evans wrote: > I'm sponsoring the following case for myself. This case qualifies for > Architectural self-review, but I wish to record the following > information. > [snip] > User Commands elfwrap(1) > > NAME > elfwrap - wrap data in an ELF file > > SYNOPSIS > elfdump [-64] [-o relobj-file] [-z target=sparc | x86] > data-file... Shouldn't this be "elfwrap" instead of "elfdump" ? :-) > DESCRIPTION [snip] > The basename(1) of each data file is used to create various > pieces of ELF information. For example, if the input data > file is ISV/isv-data, the following ELF information is > created within the relocatable object. What about adding an option to override "basename" with a different string ? ---- Bye, Roland P.S.: The data are read-only, right ? Or can I create read-write data sections with this utilty, too ? -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From casper@holland.sun.com Mon Mar 17 11:24:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2HIOUKI021685 for ; Mon, 17 Mar 2008 11:24:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2HIOQBQ006592 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Tue, 18 Mar 2008 02:24:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXW00HA30GP7Q00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Mon, 17 Mar 2008 11:24:25 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXW0071I0GLU060@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Mon, 17 Mar 2008 11:24:22 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m2HIOIWF004148; Mon, 17 Mar 2008 18:24:18 +0000 (GMT) Date: Mon, 17 Mar 2008 19:24:18 +0100 From: Casper.Dik@sun.com Subject: Re: 2008/198: elfwrap - wrap data in an ELF file In-reply-to: <47DEB29A.8080408@Sun.COM> Sender: casper@holland.sun.com To: Darren J Moffat Cc: Rod.Evans@sun.com, psarc-ext@sun.com Message-id: <200803171824.m2HIOIWF004148@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47DEAD5D.9080807@sun.com> <47DEB29A.8080408@Sun.COM> Status: RO Content-Length: 851 >> A request from the "ddi" folks (6675591), for a means of wrapping firmware >> updates into an object that can be easily loaded by a device driver, has >> triggered the creation of a new generic utility, elfwrap(1). The new >> elfwrap(1) man page says it all. Plus, an update to ddli_modopen(9f) >> provides a suitable cross reference. > >This case seems to be somewhat related to "2008/151 Pluggable >fwflash(1M). The relation I'm seeing is that they are both related to >firmware updates. I don't think it's quite the same thing. The "firmware" fwflash "flashes" resides in flash; the "firmware" loaded into devices is often not "firm" but rather "soft" and disappears on power failure. Save a few $$ on making your device by dispensing with the flash RAM. It does not make much sense for the kernel to load persistent flash. Casper From Rod.Evans@sun.com Mon Mar 17 11:24:39 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2HIOdk9021702 for ; Mon, 17 Mar 2008 11:24:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2HIOcke023481 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 Mar 2008 12:24:38 -0600 (MDT) 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 <0JXW00D090H28S00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Mar 2008 11:24:38 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXW00BSC0H1IL40@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Mar 2008 11:24: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.2+Sun/8.14.2) with ESMTP id m2HIOb9x132156; Mon, 17 Mar 2008 11:24:37 -0700 (PDT) Date: Mon, 17 Mar 2008 11:23:21 -0700 From: Rod Evans Subject: Re: 2008/198: elfwrap - wrap data in an ELF file In-reply-to: <47DEB67F.937EC7B6@nrubsig.org> To: Roland Mainz Cc: psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <47DEB719.8040706@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47DEAD5D.9080807@sun.com> <47DEB67F.937EC7B6@nrubsig.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1025 Roland Mainz wrote: > Rod Evans wrote: >> I'm sponsoring the following case for myself. This case qualifies for >> Architectural self-review, but I wish to record the following >> information. >> > [snip] >> User Commands elfwrap(1) >> >> NAME >> elfwrap - wrap data in an ELF file >> >> SYNOPSIS >> elfdump [-64] [-o relobj-file] [-z target=sparc | x86] >> data-file... > > Shouldn't this be "elfwrap" instead of "elfdump" ? :-) Yes. Mr. Plocher already beat you to it. Guess what man page template I used :-) > >> DESCRIPTION > [snip] >> The basename(1) of each data file is used to create various >> pieces of ELF information. For example, if the input data >> file is ISV/isv-data, the following ELF information is >> created within the relocatable object. > > What about adding an option to override "basename" with a different > string ? Anything is possible. Initially, I strived for simplicity. -- Rod. From Vladimir.Marek@sun.com Tue Mar 18 01:17:40 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2I8Hdjn021629 for ; Tue, 18 Mar 2008 01:17:40 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2I8Hb3N018966 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 18 Mar 2008 08:17:38 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXX00B0331DE400@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Mar 2008 01:17:37 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXX00I6E31BACD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Mar 2008 01:17:36 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2I8HZ9i020675 for ; Tue, 18 Mar 2008 08:17:35 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXX001012ZU1G00@fe-emea-10.sun.com> (original mail from Vladimir.Marek@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Mar 2008 08:17:35 +0000 (GMT) Received: from @ ([129.157.18.82]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXX00J223191KB0@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Mar 2008 08:17:35 +0000 (GMT) Date: Tue, 18 Mar 2008 09:17:33 +0100 From: Vladimir Marek Subject: Re: 2008/198: elfwrap - wrap data in an ELF file In-reply-to: <47DEAD5D.9080807@sun.com> Sender: Vladimir.Marek@sun.com To: psarc-ext@sun.com Mail-followup-to: psarc-ext@sun.com Message-id: <20080318081733.GI14459@pub> MIME-version: 1.0 Content-type: multipart/signed; boundary=rwgQ89ZNnFUwFHTC; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47DEAD5D.9080807@sun.com> User-Agent: Mutt/1.5.17 (2008-01-29) Status: RO Content-Length: 1249 --rwgQ89ZNnFUwFHTC Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [...] > -z target=3Dsparc | x86 > > Specifies the machine type for the output relocatable > object. Supported targets are sparc and x86. The 32bit > machine type for the specified target is used unless the > -64 option is also present, in which case the > corresponding 64bit machine type is used. By default, > the relocatable object that is generated is 32bit for > the machine one which elfwrap is executed. [...] Out of curiosity, would it be possible to have one 'universal' binary for both sparc and x86? The real binaries could be wrapped as data, but there would have to be some sort of universal bootloader which would pick the appropriate one. Or is it completely outside of this scope? Thank you --=20 Vlad --rwgQ89ZNnFUwFHTC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (SunOS) iEYEARECAAYFAkffep0ACgkQqVN0MVP42YwOQwCg12wYph61sOKR4fnvnTUK/EKX KEcAoK5BCZTuoeab4LotgLw93CgTcwVc =w6xq -----END PGP SIGNATURE----- --rwgQ89ZNnFUwFHTC-- From Rod.Evans@sun.com Wed Mar 19 12:33:30 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JJXTLg027814 for ; Wed, 19 Mar 2008 12:33:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2JJX97O008343; Wed, 19 Mar 2008 19:33:28 GMT 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 <0JXZ0030DSZRMO00@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 13:33:27 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ00MW1SZQJT30@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 13:33:26 -0600 (MDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2JJXQNd478963; Wed, 19 Mar 2008 12:33:26 -0700 (PDT) Date: Wed, 19 Mar 2008 12:32:08 -0700 From: Rod Evans Subject: Re: 2008/198: elfwrap - wrap data in an ELF file In-reply-to: <200803171833.m2HIXam01191@domus.sfbay.sun.com> To: psarc-ext@sun.com Cc: Vladimir.Marek@sun.com Reply-to: Rod.Evans@sun.com Message-id: <47E16A38.6020101@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803171833.m2HIXam01191@domus.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 591 Vladimir.Marek@sun.com wrote: > Out of curiosity, would it be possible to have one 'universal' binary > for both sparc and x86? The real binaries could be wrapped as data, but > there would have to be some sort of universal bootloader which would > pick the appropriate one. Or is it completely outside of this scope? I guess if we had a 'universal' binary format, elfwrap(1), or something similar could be updated to create such a file. A lot of other utilities, including the kernel's exec(2) and file mapping, would have to be visited too. Not a trivial piece of work :-) -- Rod. From roland.mainz@nrubsig.org Wed Mar 19 12:58:54 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JJwrb2028670 for ; Wed, 19 Mar 2008 12:58:54 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2JJwdR2020057; Wed, 19 Mar 2008 19:58:51 GMT 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 <0JXZ0040HU62AO00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 12:58:50 -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 <0JXZ001DPU6258F0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 12:58:50 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2JJfh63015200; Wed, 19 Mar 2008 19:58:50 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay43i.sun.com with ESMTP id BT-MMP-1258746; Wed, 19 Mar 2008 19:58:49 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.sun.com with ESMTP id BT-MMP-3105181; Wed, 19 Mar 2008 19:58:32 +0000 (Z) Received: from mail-in-13.arcor-online.net ([151.189.21.53] [151.189.21.53]) by relay4i.sun.com with ESMTP id BT-MMP-32416588; Wed, 19 Mar 2008 19:58:31 +0000 (Z) Received: from mail-in-16-z2.arcor-online.net (mail-in-16-z2.arcor-online.net [151.189.8.33]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id 7F5941E505C; Wed, 19 Mar 2008 20:58:30 +0100 (CET) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mail-in-16-z2.arcor-online.net (Postfix) with ESMTP id 6B38D2540B6; Wed, 19 Mar 2008 20:58:30 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-059-004-066.pools.arcor-ip.net [84.59.4.66]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 25C7D3425EA; Wed, 19 Mar 2008 20:58:29 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m2JJwRGf007974; Wed, 19 Mar 2008 20:58:28 +0100 (CET) Date: Wed, 19 Mar 2008 20:58:27 +0100 From: Roland Mainz Subject: Re: 2008/198: elfwrap - wrap data in an ELF file Sender: gisburn@jupiterb48.nrubsig.org To: Rod.Evans@sun.com Cc: psarc-ext@sun.com Message-id: <47E17063.27F8E750@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/6305/Wed Mar 19 08:32:53 2008 on mail-in-09.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=-2.6/5.0, scanned in 0.179sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47DEAD5D.9080807@sun.com> <47DEB67F.937EC7B6@nrubsig.org> <47DEB719.8040706@sun.com> Status: RO Content-Length: 1338 Rod Evans wrote: > Roland Mainz wrote: > > Rod Evans wrote: [snip] > >> SYNOPSIS > >> elfdump [-64] [-o relobj-file] [-z target=sparc | x86] > >> data-file... > > > > Shouldn't this be "elfwrap" instead of "elfdump" ? :-) > > Yes. Mr. Plocher already beat you to it. Guess what man page template > I used :-) :-) > >> DESCRIPTION > > [snip] > >> The basename(1) of each data file is used to create various > >> pieces of ELF information. For example, if the input data > >> file is ISV/isv-data, the following ELF information is > >> created within the relocatable object. > > > > What about adding an option to override "basename" with a different > > string ? > > Anything is possible. Initially, I strived for simplicity. Ok... but a "basename" option may be usefull to avoid "ugly" filenames in the filesystem, e.g. mangled C++ names may not look "pretty" when they appear in the filesystem (and for more complex C++ symbol names you may hit the maximum filename length sooner or later...). BTW: What about question about "read-only" in my previous email... does this matter in this case ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From Rod.Evans@sun.com Wed Mar 19 13:30:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JKU9b0029798 for ; Wed, 19 Mar 2008 13:30:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2JKU9nn005396 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 19 Mar 2008 14:30:09 -0600 (MDT) 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 <0JXZ0070RVM7NJ00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Mar 2008 14:30:07 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ00MECVM5JP70@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Mar 2008 14:30:05 -0600 (MDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2JKU42w490692; Wed, 19 Mar 2008 13:30:05 -0700 (PDT) Date: Wed, 19 Mar 2008 13:28:47 -0700 From: Rod Evans Subject: Re: 2008/198: elfwrap - wrap data in an ELF file In-reply-to: <47E17063.27F8E750@nrubsig.org> To: Roland Mainz Cc: psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <47E1777F.4020806@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47DEAD5D.9080807@sun.com> <47DEB67F.937EC7B6@nrubsig.org> <47DEB719.8040706@sun.com> <47E17063.27F8E750@nrubsig.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1150 Roland Mainz wrote: >>> What about adding an option to override "basename" with a different >>> string ? >> Anything is possible. Initially, I strived for simplicity. > > Ok... but a "basename" option may be usefull to avoid "ugly" filenames > in the filesystem, e.g. mangled C++ names may not look "pretty" when > they appear in the filesystem (and for more complex C++ symbol names you > may hit the maximum filename length sooner or later...). Sure, it would be easy to add an option to provide for this if required. (although I'd mot sure why you'd come up with a mangled C++ name in the first place that you'd have to override). > BTW: What about question about "read-only" in my previous email... does > this matter in this case ? Sorry, missed this one. Presently the data is simply tagged SHF_ALLOC, as those that have requested to use elfwrap() simply wanted to read data in. Again, options could allow you to set any sections flags, and rather than a simplistic -w (write) flag I'd probably go the route of allowing any valid SHF_ flag to be set. There again, you could elfwrap(1) something and elfedit(1) it after :-) -- Rod. From roland.mainz@nrubsig.org Wed Mar 19 14:35:18 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JLZIIZ002806 for ; Wed, 19 Mar 2008 14:35:18 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2JLZFOR002474; Wed, 19 Mar 2008 21:35:16 GMT 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 <0JXZ00E01YMR4000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 14:35:15 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ0042RYMQBD70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 14:35:15 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2JLOV0k023069; Wed, 19 Mar 2008 21:35:14 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay14i.sun.com with ESMTP id BT-MMP-376708; Wed, 19 Mar 2008 21:35:14 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp11es.sun.com with ESMTP id BT-MMP-3152091; Wed, 19 Mar 2008 21:35:13 +0000 (Z) Received: from mail-in-11.arcor-online.net ([151.189.21.51] [151.189.21.51]) by relay1i.sun.com with ESMTP id BT-MMP-3296260; Wed, 19 Mar 2008 21:35:13 +0000 (Z) Received: from mail-in-16-z2.arcor-online.net (mail-in-16-z2.arcor-online.net [151.189.8.33]) by mail-in-11.arcor-online.net (Postfix) with ESMTP id A46E52091B0; Wed, 19 Mar 2008 22:35:12 +0100 (CET) Received: from mail-in-17.arcor-online.net (mail-in-17.arcor-online.net [151.189.21.57]) by mail-in-16-z2.arcor-online.net (Postfix) with ESMTP id 8F6B8254152; Wed, 19 Mar 2008 22:35:12 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-059-004-066.pools.arcor-ip.net [84.59.4.66]) by mail-in-17.arcor-online.net (Postfix) with ESMTP id 60F712BB8BB; Wed, 19 Mar 2008 22:35:12 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m2JLZA95007999; Wed, 19 Mar 2008 22:35:10 +0100 (CET) Date: Wed, 19 Mar 2008 22:35:09 +0100 From: Roland Mainz Subject: Re: 2008/198: elfwrap - wrap data in an ELF file Sender: gisburn@jupiterb48.nrubsig.org To: Rod.Evans@sun.com Cc: psarc-ext@sun.com Message-id: <47E1870D.6AAF2FD5@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/6305/Wed Mar 19 08:32:53 2008 on mail-in-17.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=-2.6/5.0, scanned in 0.089sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47DEAD5D.9080807@sun.com> <47DEB67F.937EC7B6@nrubsig.org> <47DEB719.8040706@sun.com> <47E17063.27F8E750@nrubsig.org> <47E1777F.4020806@sun.com> Status: RO Content-Length: 1839 Rod Evans wrote: > Roland Mainz wrote: > >>> What about adding an option to override "basename" with a different > >>> string ? > >> Anything is possible. Initially, I strived for simplicity. > > > > Ok... but a "basename" option may be usefull to avoid "ugly" filenames > > in the filesystem, e.g. mangled C++ names may not look "pretty" when > > they appear in the filesystem (and for more complex C++ symbol names you > > may hit the maximum filename length sooner or later...). > > Sure, it would be easy to add an option to provide for this if required. > (although I'd mot sure why you'd come up with a mangled C++ name in the > first place that you'd have to override). What about C++ classes where a class member contains such data (OkOk... you could use a global variable containing the data generated by "elfwrap" and init the member variable in the constructor etc.) ? > > BTW: What about question about "read-only" in my previous email... does > > this matter in this case ? > > Sorry, missed this one. Presently the data is simply tagged SHF_ALLOC, > as those that have requested to use elfwrap() simply wanted to read data > in. Again, options could allow you to set any sections flags, and rather > than a simplistic -w (write) flag I'd probably go the route of allowing > any valid SHF_ flag to be set. Ok... ... is it possible to make "elfwrap" tag the data as "shareable between processes" (e.g. read-only) by default ? Otherwise we have a similar issue like the current Sun Studio 10/11 "cc" behaviour for string literals which eat memory per process instead of being shared between processes (unless you use "-xstrconst") ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From Rod.Evans@sun.com Wed Mar 19 15:01:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JM1ioH004048 for ; Wed, 19 Mar 2008 15:01:45 -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 m2JM1a1L014616 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 20 Mar 2008 06:01:43 +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 <0JXZ0046FZUU4M00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Mar 2008 15:01:42 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ000PCZUTFG80@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Mar 2008 15:01:41 -0700 (PDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2JM1ffV509291; Wed, 19 Mar 2008 15:01:41 -0700 (PDT) Date: Wed, 19 Mar 2008 15:00:24 -0700 From: Rod Evans Subject: Re: 2008/198: elfwrap - wrap data in an ELF file In-reply-to: <47E1870D.6AAF2FD5@nrubsig.org> To: Roland Mainz Cc: psarc-ext@sun.com Reply-to: Rod.Evans@sun.com Message-id: <47E18CF8.2030303@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47DEAD5D.9080807@sun.com> <47DEB67F.937EC7B6@nrubsig.org> <47DEB719.8040706@sun.com> <47E17063.27F8E750@nrubsig.org> <47E1777F.4020806@sun.com> <47E1870D.6AAF2FD5@nrubsig.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1257 Roland Mainz wrote: > Ok... > ... is it possible to make "elfwrap" tag the data as "shareable between > processes" (e.g. read-only) by default ? Otherwise we have a similar > issue like the current Sun Studio 10/11 "cc" behaviour for string > literals which eat memory per process instead of being shared between > processes (unless you use "-xstrconst") ... It is read-only. For example, from a standard ELF relocatable object: Section Header[4]: sh_name: .rodata sh_addr: 0 sh_flags: [ SHF_ALLOC ] sh_size: 0 sh_type: [ SHT_PROGBITS ] Section Header[5]: sh_name: .data sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ] sh_size: 0 sh_type: [ SHT_PROGBITS ] The .rodata (read-only data) section only has SHF_ALLOC flag set. The .data section is writable (and non-sharable) having the SHF_WRITE flag set. elfwrap(1) produces: Section Header[1]: sh_name: .passwd sh_addr: 0 sh_flags: [ SHF_ALLOC ] sh_size: 0x395 sh_type: [ SHT_PROGBITS ] All allocatable, non-writable sections are combined by ld(1) into the text segment, which is read-only and sharable between all processes. -- Rod.