2008/198: elfwrap - wrap data in an ELF file
Rod Evans
Rod.Evans at sun.com
Mon Mar 17 10:41:49 PDT 2008
--------------------------------------------------------------------------
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.
More information about the opensolaris-arc
mailing list