PSARC/2010/022 Linker-editors: Symbol Capabilities
On 01/26/10 06:03 AM, Rainer Orth wrote: > Rod Evans writes: > >> The compiler engineers have also asked for a means of selecting between a >> family of functions contained within the same dynamic object. Each family >> member is compiled differently to use various capabilities, where these >> capabilities can be provided by different systems. > > Not this case, but how is one supposed to use this directly from the > compiler/assembler without linker mapfiles? Might be interesting to add > support to GCC in the future. The exact method would be up to the compilers. The high-level idea was that some new compiler option(s) might lead the compiler to generate one or more variants of the functions within a source file. For example, if a source file contained foo(), they might generate a foo%sun4u and foo%sun4v, and associate each function with a set of capabilities that were directed by the compilers options. The generated source file would have the same ELF infrastructure as a relocatable object generated with -z symbolcap. ld(1) could then process this file, as it does now with -z symbolcap generated files, and create the associated dynamic object - no mapfiles need be involved. > A couple of other questions: > > * You're currently using v1 mapfile syntax in the LLM excerpt. I >suppose this is because this case requests patch/micro binding, but it >should state the v2 syntax, too. You've caught us in the middle of two projects, the symbol capabilities and the new mapfile implementation (PSARC/2009/688). The LLM materials for this case don't include changes for 2009/688. However, we have updates for the LLM for 2009/688, and they are being merged together as we speak. The final LLM will have all examples using the v2 syntax. Symbol capabilities can be driven off of v1 or v2 mapfile syntax. > * In the example on p.76 of the LLM, what happens if the machine >provides e.g. both MMX and SSE. Which instance of foo will be used in >this case? I suppose there is a similar ordering like the one >described on p.380 (descending order of capability values), but is >this supposed to be documented or implementation defined? It should be clearer than it is :-) The largest value wins. > * Does LD_CAP_FILES match the file names of shared objects, or their >SONAMEs, exact or substring match? The doc states: The most flexible means of defining LD_CAP_FILES is to use the base name of the required files. $ LD_HWCAP=-sse2 LD_CAP_FILES=libfoo.so,libbar.so ./main The files base name is the SONAME. The implementation actually uses the base name, full path name, or even alias names (symlinks) to match any LD_CAP_FILES requirements. -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!
PSARC/2010/022 Linker-editors: Symbol Capabilities
This case was approved at PSARC Feb 3rd 2010. http://sac.sfbay/Archives/Minutes/PSARC/2010/20100203.html -- Rod Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!
PSARC/2010/089 Removal of AV_386_PAUSE and AV_386_MON
I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. An escalation has arisen, on S10u1, where an application identified with a AV_386_PAUSE hardware capability, does not run, because the kernel does not export the AV_386_PAUSE capability. See 6478684. However, the "pause" capability, a 'rep; nop', is present on all x86 CPU's. Originally, it was felt that exporting the PAUSE capability from all x86 CPU's would be an appropriate fix. But, Tim Marsland has since evaluated this issue, and the clean fix is felt to be removing the PAUSE (and MON) capabilities all together, as it was a mistake to invent then in the first place. From 6478684: Sigh. We should never have added AV_386_PAUSE to the set of flags exported by the getisax(2) API in the first place. The primary goal of this API and all the cross-checking etc. we perform is to allow the presence or absence of new instructions to be determined by applications. This makes no sense for the 'pause' instruction, as by virtue of its encoding it is already *is* present in all x86 CPUs - all CPUs can execute 'rep; nop' painlessly and with no negative side-effects. Code that might ever find itself running spin loops on a hyperthreaded processor should just use the pause instruction - no need to check anything about the environment or processor. The only interesting thing the pause instruction does is non-architectural. Suggest that rather than test and disqualify any binary on the basis of this bit being set or otherwise, we simply exclude it from any tests we make, and stop printing out whether or not the value is set. The relevant field in the header file should be labelled 'defined by mistake: reserved'. The kernel code that sets it should be removed. And while looking at this, I noticed another kind of mistake - AV_386_MON, the monitor/mwait instructions can only be used in ring 0, and thus should also NOT be exported via the getisax(2) mechanism. Thus AV_386_MON and AV_386_PAUSE should both be ignored and marked 'defined by mistake: reserved' in the header file. Aux vectors are Solaris specific. The following aux vector flags are defined in sys/auxv_386.h #define AV_386_PAUSE0x02000 /* use pause insn (in spin loops) */ #define AV_386_MON 0x08000 /* monitor/mwait insns */ Various tools within the OS can display these capabilities (elfdump, pargs) and the link-editor allows symbolic definitions for these capabilities to be defined within mapfiles. The display and translation of all capabilities values is centralized within the usr/src/common/elfcap components. We would like to: i.prevent any future use of PAUSE or MON ii. prevent any display of these symbolic tokens (but retain display of the associated numeric token) iii. prevent ld.so.1 from using these capabilities in its verification of loading objects By removing the AV_386_PAUSE and AV_386_MON from auxv_386.h, and removing the PAUSE and MON data structures from elfcap.c:hw1_386[], we achive i. and ii. In addition, ld.so.1 has been modified to ignore the value of these withdrawn capability bits in any object containing them. Thus we achieve iii. Any existing code that references the definitions AV_386_PAUSE or AV_386_MON will fail to compile against the new version of auxv_386.h. Within the OS, only elfcap.c, and uts/i86pc/os/cpuid.c reference these flags, and they have been purged. The x86 assembler also references AV_386_PAUSE, and is being fixed under 6933101. There is no evidence of any other use (although outside uses have copied these definitions to their own headers - readelf.h), but should there be any reference to these definition, a compilation failure is going to alert the developer into questioning why they believe these flags are useful. Capabilities are only used on Solaris. To the extent that other systems know these bits as MON and PAUSE, there is no problem, because we're not giving them new meanings. We're simply purging their names, and ignoring them. -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!
2007/336 Bundled BCC for Solaris
RESENDING to psarc-ext.
I'm sponsoring the following fasttrack - timeout 06/15/2007
1. Summary and motivation.
This proposal seeks to bundle bcc with Solaris. bcc is an open-source 8086
real-mode compiler. It is part of the Dev86 [1] Linux 8086 development
environment. The Xen hypervisor [2] requires bcc in order to build the
firmware for its fully-virtualized ("HVM") domain capability.
Beyond building Xen, bcc will be useful for the development of other
virtualization technologies on Solaris. For example, bcc is needed to
compile VirtualBox [3] for Solaris. bcc may make Solaris a friendlier
development platform for this type of low-level x86 development.
2. Technical issues of bcc inclusion.
2.1. bcc implementation and version.
Version 0.16.17 of bcc is proposed for integration. It was released on
January 23rd, 2005, indicating a slow and stable rate of change. Along
with
the compiler, the assembler and linker are also proposed for integration.
Options for the commands provided are documented in the man pages, which
have been placed in the case materials directory.
3. Interfaces.
The following interfaces are proposed.
Stability:
Location Uncommitted
Invocation Volatile
Human-readable Output Volatile
Exported Interfaces:
SUNWbcc Uncommitted Package name
/usr/bin/ar86 Uncommitted Command
/usr/bin/as86 Uncommitted Command
/usr/bin/bccUncommitted Command
/usr/bin/ld86 Uncommitted Command
4. References.
[1] http://homepage.ntlworld.com/robert.debath/
[2] http://xen.sourceforge.net
[3] http://www.virtualbox.org
Release Binding:Update
--
Rod.
2008/583: add gld options to ld(1)
I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. Folks who build with "configure" frequently run into situations where options appropriate for gld (GNU's ld) are passed to ld(1). ld(1) provides a nice usage message, and exits, leaving the user to fix the configure process or edit the Makefiles produced by configure to supply the appropriate Solaris option. This case adds a family of gld options to ld(1). These options are the most common found to have been passed to ld(1). These options are also simple translations from gld to ld(1) - ie. the options provide identical functionality with gld and ld(1). Many other gld options exist. Some have no ld(1) equivalent, or require a modification in behavior to mimic gld expectations. Some options might be considered no-ops to ld(1). This case does not address any of these options, as they have not been discovered to be common configure issues. There is however, nothing about this case, that would prohibit the addition of more gld options in future. The changes for this proposal are being carried out under: 6744003 ld(1) could provide better argument processing diagnostics And the associated man page: 6747570 ld(1) updates (6744003) require man pages changes. The following gld options are being added to ld(1): Gld option Solaris ld(1) equivalent --allow-multiple-definition -> -z muldefs --auxiliary -> -f --entry -> -e --filter -> -F --help -> -z help --library -> -l --library-path-> -L --no-undefined -> -z defs --outfile -> -o --relocatable -> -r --strip-all -> -s --undefined -> -u --version -> -V --version-script -> -M -rpath-> -R -shared -> -G -soname -> -h --dynamic-linker -> -I Release Binding: Patch/Micro new ld options: Committed -- Rod.
2008/226: mmapfd(2) - mmap file descriptor
The following minor changes are being made to this case material to capture the comments received so far. An updated man page has been added to the materials directory. i. change name from mmapfd(2) to mmapobj(2). ii.change data structure name, and associated flags to follow mmapobj convention. iii. change values for mr_flags field of mmapobj_result_t (the present flags are mutually exclusive). #define MOBJ_PADDING 0x1 #define MOBJ_HDR_ELF 0x2 #define MOBJ_HDR_AOUT0x3 iv.change mr_prot field of mmapobj_result_t from an int to uint_t. v. various other small man page updates. -- Rod.
PSARC/2007/509 elfedit
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.
PSARC/2007/509 elfedit
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.
2007/559: new symbol visibilities - EXPORTED, SINGLETON, and ELIMINATE
I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. 6602451 documents the requirements for some new symbol visibilities. These visibilities are defined as ELF_ST_VISIBILITY() values within a symbols "st_other" field. As this is a "public" ELF field, the proposal was passed around several ELF vendors. See: http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc1566616 The proposal started with our requirement to add STV_SINGLETON and STV_ELIMINATE. However, we found that SCO had already added to this public arena with STV_EXPORTED. We therefore intend to add three new visibilities: STV_EXPORTED Indicates that a symbol is to remain global and can not be demoted or eliminated by any other linking technique. STV_SINGLETON Indicates that only once instance of the symbol can be bound to by any reference. This is a long standing C++ requirement that has relied upon interposition (but has been broken by several linking techniques, such as symbol scoping, -Bsymbolic and direct-binding). STV_ELIMINATE Indicates that a symbol should be eliminated from any symbol tables. Required by DTrace. This fast track also adds a new observability option to lari(1): User Commands lari(1) SYNOPSIS lari [-bCDsVv] [-a | -i | -o] file | directory... | lari [-CDosv] [-m [-d mapdir]] file | -V | Appends interesting symbol visibilities. Symbols that | are defined as singleton or are defined protected are | identified with this option. | Public Header additions: usr/src/uts/common/sys/elf.h #define STV_EXPORTED4 #define STV_SINGLETON 5 #define STV_ELIMINATE 6 usr/src/uts/common/sys/link.h #define DF_1_SINGLETON 0x0200 Release Binding: Patch/Micro sys/elf.h additionsCommited sys/link.h additions Commited lari(1) -V Commited -- Rod.
2009/054: dlinfo(3c) - segment mapping retrieval
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 has been made for ld.so.1 to return an objects segment mapping
information. This method of obtaining the data would be more light weight
than having to go through things like /proc.
6237063 request extension to dl* family to provide segment bounds
information
With the approach of mmapobj(2), this request was put on hold, so that we
could return a public/consistent data structure. mmapobj(2) has integrated,
and ld.so.1 now uses it(6686372).
dlinfo() will return mmapobj_result_t data by using two new flags:
> #define RTLD_DI_MMAPS12 /* obtain objects mappings or */
> #define RTLD_DI_MMAPCNT 13 /* mapping count */
An auxiliary structure is used to maintain the data:
> typedef struct {
> uint_t dlm_cnt;/* number of mapings */
> mmapobj_result_t *dlm_maps; /* mapping information */
> } Dl_mapinfo_t;
The user will first determine the number of mappings using a RTLD_DI_MMAPCNT
request, and then provide the appropriate buffer to a RTLD_DI_MMAPS request.
This model follows the RTLD_DI_SERINFOSIZE/RTLD_DI_SERINFO model, approved
with PSARC/2000/164 (bug id 4239213).
Standard C Library Functions dlinfo(3C)
.
RTLD_DI_MMAPCNT
Initialize a Dl_mapinfo_t structure for the handle that
is specified, for use in a RTLD_DI_MMAPS request. The p
argument is a Dl_mapinfo_t pointer (Dl_mapinfo_t *p). On
return from a RTLD_DI_MMAPCNT request, the dlm_cnt
member indicates the number of segment mappings that the
associated object uses.
To obtain the complete mapping information for an
object, a mmapobj_result_t array for dlm_cnt entries
must be allocated and assigned to the dlm_maps member.
This initialized structure is then passed to a
RTLD_DI_MMAPS request. See EXAMPLES.
RTLD_DI_MMAPS
Obtain segment mapping information for the handle that
is specified. The p argument is a Dl_mapinfo_t pointer
(Dl_mapinfo_t *p). This structure must be initialized
from a previous RTLD_DI_MMAPCNT request.
Segment mapping information is provided in an array of
mmapobj_result_t structures that originate from the mma-
pobj(2) of the associated object. The dlm_cnt member
from a previous RTLD_DI_MMAPCNT request must be used to
allocate a mmapobj_result_t array. This array should be
assigned to the dlm_maps member. This initialized struc-
ture is then passed to a RTLD_DI_MMAPS request, where
the segment mapping information is copied to the allo-
cated mmapobj_result_t array. See EXAMPLES.
.
Example 2: Use dlinfo() to obtain segment information.
The following example demonstrates how a dynamic object can
inspect its segment mapping information. For simplicity,
error checking has been omitted
Dl_mapinfo_t mi;
uint_t cnt;
/* determine the number of segment mappings */
dlinfo(RTLD_SELF, RTLD_DI_MMAPCNT, &mi);
/* allocate the appropriate mapping array */
mi.dlm_maps = malloc(mi.dlm_cnt * sizeof (mmapobj_result_t));
/* obtain the mapping information */
dlinfo(RTLD_SELF, RTLD_DI_MMAPS, &mi);
for (cnt = 0; cnt < mi.dlm_cnt; cnt++) {
(void) printf("addr=%x - memory size=%x\n",
mi.dlm_maps[cnt].mr_addr, mi.dlm_maps[cnt].mr_msize);
}
Release binding:Patch/Micro
dlfcn.h:
Dl_mapinfo_t Committed.
RTLD_DI_SERINFO Committed.
RTLD_DI_SERINFOSIZE Committed.
--
Rod.
2009/054: dlinfo(3c) - segment mapping retrieval
Rod Evans wrote: > > Release binding:Patch/Micro > >dlfcn.h: > Dl_mapinfo_t Committed. > RTLD_DI_SERINFOCommitted. > RTLD_DI_SERINFOSIZECommitted. Sigh blindly cutting and pasting ... that should be: Release binding:Patch/Micro dlfcn.h: Dl_mapinfo_t Committed. RTLD_DI_MMAPCNTCommitted. RTLD_DI_MMAPS Committed. -- Rod.
2009/054: dlinfo(3c) - segment mapping retrieval
> > Release binding:Patch/Micro > >dlfcn.h: > Dl_mapinfo_t Committed. > RTLD_DI_SERINFOCommitted. > RTLD_DI_SERINFOSIZECommitted. Sigh blindly cutting and pasting ... that should be: Release binding:Patch/Micro dlfcn.h: Dl_mapinfo_t Committed. RTLD_DI_MMAPCNTCommitted. RTLD_DI_MMAPS Committed. -- Rod.
2009/054: dlinfo(3c) - segment mapping retrieval
> An auxiliary structure is used to maintain the data:
>
> > typedef struct {
> > uint_tdlm_cnt;/* number of mapings */
> > mmapobj_result_t *dlm_maps;/* mapping information */
> > } Dl_mapinfo_t;
Minor update, this data structure has been expanded to provide
a return count of the mappings that were filled in by ld.so.1.
A user is free to use a constant array to represent a maximum
number of mappings, but ld.so.1 will return how many it provided.
> typedef struct {
> mmapobj_result_t *dlm_maps; /* mapping information */
> uint_t dlm_acnt; /* number of dlm_maps mappings */
> uint_t dlm_rcnt; /* number of returned mappings */
> } Dl_mapinfo_t;
Minor modes to the man page description and example have been
supplied with the associated bug report (6237063).
--
Rod.
2008/148: new ldd(1) -p option
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
2008/148: new ldd(1) -p option
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
2008/198: elfwrap - wrap data in an ELF file
--
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] 0x 0x SECT LOCL D 0 .passwd
[3] 0x 0x SECT LOCL D 0 .group
[7] 0x 0x02f0 OBJT GLOB D 0 .passwd passwd_start
[8] 0x02f0 0x OBJT GLOB D 0 .passwd passwd_end
[9] 0x 0x0121 OBJT GLOB D 0 .group group_start
[10] 0x0121 0x 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
#includestdio.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
2008/198: elfwrap - wrap data in an ELF file
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.
2008/198: elfwrap - wrap data in an ELF file
Vladimir.Marek at 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.
2008/198: elfwrap - wrap data in an ELF file
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.
2008/198: elfwrap - wrap data in an ELF file
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.
2008/226: mmapfd(2) - mmap file descriptor
I'm sponsoring the following case for Mike Corcoran. Time out 04/07/08. The case introduces a new system call, mmapfd(2). This call is primarily targeted for use by ld.so.1(1), and provides for the efficient mapping of ELF files (and 4.x AOUT files). Release Binding: Patch/Micro mmapfd(2): Consolidation Private -- 1. Introduction 1.1. Project/Component Working Name: mmapfd: mmap file descriptor 1.2. Name of Document Author/Supplier: Michael Corcoran 1.3. Date of This Document: 03/24/08 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: William.Franklin at sun.com 1.4.4. The name of your business unit: Software 1.5. Email Aliases: 1.5.1. Responsible Manager: Darrin.Johnson at sun.com 1.5.2. Responsible Engineer:Michael.Corcoran at sun.com 2. Project Summary 2.1. Project Description: mmapfd is a new system call targeted for use in mapping files that need to be interpreted. The runtime linker (ld.so.1) will make use of this system call to map dynamic objects. Both ELF and AOUT (4.x) file formats are supported. Under the covers, the OS can optimize the placement of these interpreted dynamic objects. 4. Technical Description: 4.1. Details: mmapfd is a new system call which can interpret and map ELF and AOUT (4.x) objects. This system call allows the interpretation and mapping of ELF and AOUT files to be carried out completely by the kernel rather than by ld.so.1. mmapfd also provides for mapping a whole file, without interpretation in a read only mode. mmapfd returns a description of the mappings that have been used to represent the associated file. This data is used by ld.so.1 to continue processing the file - searching for dependencies, symbols and performing relocations. The data provides for individual operations to be carried out for each mapping, ie. munmap(2), mprotect(2), etc. All of the mapping capabilities that ld.so.1 provides today, such as the addition of padding (for dbx) and fixed address object mapping, are available with mmapfd. In the past, there have been many requests for ld.so.1 to handle different platforms in different manners by passing new flags or by trying to have ld.so.1 discover what to do for a given platform. By creating a single mmapfd interface, these special flags and behaviors can be removed from ld.so.1, resulting in a much cleaner ld.so.1 and more flexibility for different platforms to perform optimizations. For example, one optimization is for the kernel to use large pages where applicable. Another optimization might be to use the same virtual address for the same object among different processes. These optimizations can be achieved more easily as the kernel will now interpret the program headers of the associated file, and thus can deduce segment size and segment alignment requirements, together with the files used throughout the system. Future projects which can build off of the new mmapfd system call include: - Having elfexec and mmapfd share a common set of routines to do all mapping of ELF files. This will provide a centralized location for interpreting all ELF objects which will be easier to support and provide a consistent behavior for all applications. - Having the kernel do hardware capability checking, thus relieving ld.so.1 from having to do this work, while mapping in an ELF file. Once again, elfexec and mmapfd can share common interfaces so there is no duplication of code and consistent behaviors. - Allow DTrace better access to ELF information. DTrace engineers have been looking to access DTrace information from within an ELF file within critical regions. This DTrace information can be gathered as an extension to the ELF file processing already undertaken by mmapfd. - Allow new file types to be interpreted in the future via this central interface. 4.2. Bug/RFE Number(s): 6502792: Same dynamic libraries should be mapped at the same virtual addresses in different processes 6561987 data vac_conflict faults on lipthread libthread libs in s10 5. Reference Docu
PSARC 2009/493 ld -z wrap option
Garrett D'Amore wrote: > Really, apart from the incursion of a little extra delay (probably one > week in this case), there is nothing else needed at this point if your > case is turned into a fast track, except in the unlikely event that > someone takes exception with the case. I still don't see the point. We don't decide upon submitting a fast-track, or a self-review case based on the time we wish to wait for the process to complete, we always wait a day or two after submitting a self-review to ensure we give folks time to comment. We make the distinction based upon whether we feel there's any architectural issues that might concern or be of interest to the ARC. In this case, as with most linker cases, we don't think there are. Thus, we're going to use the lightest weight process. -- Rod.
EOF of libucb [PSARC/2009/541 OnePager]
There is a large body of code, and a bunch of vectoring through tables, within ld.so.1 that support the loading/relocation and symbol lookup of 4.x applications. There's AOUT processing in exec() and mmapobj() too. And we've had oodles of fun massaging the Unified Process Model into being able to cope with two lib's within the same process (required to support sbcp's dependencies and the 4.x app). I've wanted to nuke the ld.so.1 4.x stuff a number of times, and as recently as the mmapobj() project, visited the subject again. Yes, we had to do extra work in mmpobj to make sure 4.x objects could be mapped - was it worth the effort? It's always been interesting to learn that 4.x binaries still exist. Some live in the bin directories of those watching this alias (you know who you are :-). And it wasn't so long ago that we relied on them internally (the netinstall "addclient" I recall?). Which has always made us wonder, if *we're* still using 4.x binaries then might our customers be using them too? The result is that I always backed down and left the 4.x stuff (at least in ld.so.1) as it was. I like the idea of a branded zone. I don't have a concrete opinion on the 4.x support. If there was a time for its removal, now seems as good as any. And it would certainly simplify some of my life. The counter argument is that it works (to some degree - there are only a handful of binaries I know of that I ever use to verify it's functionality), and that some customer might still be using it. The trouble is that we think it needs no more support, ie. the code's done, but mmapobj() proved we had to go do extra work to keep supporting it. I'd really like to not have to visit 4.x again. One question I've always had is why do we keep building the libraries etc? For example, to support 4.x we have /usr/lib/ld.so, which is a 4.x binary (which we probably couldn't rebuild again if we tried, the last 4.x machine I know of got taken off the net long ago), so why couldn't we package up the 4.x components and simply not build them again. We haven't changed them in years, have we? If a customer wanted them we could point them at the package, but beyond that, they're done, and they'd be out of our source base. Just thinking out loud. -- Rod.
PSARC/2009/688 Human readable and extensible ld mapfile syntax
To stir the pot some more ... If we want to change the default for all applications to be that the stack is non-executable, then why don't we have exec() do it? We already do this for amd64, no? We try and steer away from having the ELF file be a transportation medium for arbitrary aspects of process creation. I believe a similar concept was the whole large page story, where various folks wanted to tell ld(1) that they wanted large pages, and ld(1) would squirrel this intent into the ELF file, or for ld.so.1 retrieval, so that the request would be passed onto the kernel. That's why we invented mmapobj(2), to get out of this game. The user shouldn't know about large pages, let alone be expected to tell the kernel it wants them. The kernel should use the best resources available for the file in question. This seems the same concept as an executable stack. Having the user record their intent, or ld(1) do it by default for them, just seems silly. Have the kernel do for everyone. Now, what do we do for folks who want an executable stack? Well, I guess these, hopefully few, folks can use a mapfile to set an executable stack. But there's also the ABI question. Under the "Managing the Process Stack" section of the SPARC ABI, it states "On SPARC, the stack segment is read, write, and execute permissions". Interestingly, for Intel it states "On the Intel386, the stack has read and write permissions". Although I believe our default for Intel is the same as SPARC. Our model used to be that by default we built ABI compliant applications and by default provided an environment for ABI execution. Should we consider these "rules" antiquated now? and default more to a secure environment? I'm not aware of anyone really updating any ABI's anymore, and the force of evolution seems to be de-facto standards (meaning whatever Linux does :-). -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!
PSARC/2010/022 Linker-editors: Symbol Capabilities
I'm sponsoring the following Fact-Track, time out Jan 27th 2010.
---
The link-editors provide a number of means for selecting alternative
implementations at runtime. Reserved tokens can be used with runpaths
(ie. $PLATFORM), and capabilities can be recorded within dynamic objects
(ie. ELF{32|64}_Cap - $HWCAP). On SPARC, the model for using these
techniques is through numerous "psr" libraries, provided by a network of
symlinked libraries under /platform.
This "model" is rather complex, hard to maintain (at least from a packaging
point of view), and can, when the optimized functions are not heavily used,
actually lead to a runtime overhead because of searching for "psr" candidates.
The compiler engineers have also asked for a means of selecting between a
family of functions contained within the same dynamic object. Each family
member is compiled differently to use various capabilities, where these
capabilities can be provided by different systems.
To reduce "psr" overhead, and address the compiler requirements, the
capabilities that can be recorded within dynamic objects have been extended,
and an ELF infrastructure has been created that associates individual symbols
with their required capabilities. With this infrastructure, a family of
functions, each with different capability requirements, can be contained
within a single dynamic object. The runtime linker can use this infrastructure
to analyze a capabilities family at runtime, and select the best function to
bind to for the underlying system.
In other words, we can take the contents of all our libc_psr libraries and
put them in one libc.so.1. Then we can then throw away the /platform
symlinked psr libraries.
The change in the link-editors is being tracked under:
6918143 symbol capabilities
---
Presently, the capabilities that can be defined within an object are derived
from the HWCAP aux vector flags (see AV_SPARC in sys/auxv_SPARC.h and AV_386
in sys/auxv_386.h). However, these capabilities are insufficient to represent
the present "psr" incantations. The capability tags have been expanded to
provide:
i. a platform name (one or more can be applied to a capabilities group)
ii. a machine hardware name ( " " " " " ")
iii. a capabilities identifier name
The latter identifier (iii.) does not add to the capabilities definitions, but
provides a means of symbolically naming a capabilities group (this comes in
to play with the new ld(1) -z symbolcap option ... more later).
With these identifiers, we can now, for example, identify a capabilities
group that would be applicable for an "opl" system:
Symbol Capabilities:
index tag value
[4] CA_SUNW_ID sun4u-opl
[5] CA_SUNW_PLAT SUNW,SPARC-Enterprise
or, even more fun, one of the existing hwcap variants (this is "psr" variant
that gets loop-back mounted on a "psr" mount point):
Symbol Capabilities:
index tag value
[7] CA_SUNW_ID sun4u-us3-hwcap1
[8] CA_SUNW_PLAT SUNW,A70
[9] CA_SUNW_PLAT SUNW,Netra-210
[10] CA_SUNW_PLAT SUNW,Netra-240
[11] CA_SUNW_PLAT SUNW,Netra-440
[12] CA_SUNW_PLAT SUNW,Netra-CP3010
[13] CA_SUNW_PLAT SUNW,Netra-T12
[14] CA_SUNW_PLAT SUNW,Netra-T4
[15] CA_SUNW_PLAT SUNW,Sun-Blade-1000
[16] CA_SUNW_PLAT SUNW,Sun-Blade-1500
[17] CA_SUNW_PLAT SUNW,Sun-Blade-2500
[18] CA_SUNW_PLAT SUNW,Sun-Fire-15000
[19] CA_SUNW_PLAT SUNW,Sun-Fire-280R
[20] CA_SUNW_PLAT SUNW,Sun-Fire-480R
[21] CA_SUNW_PLAT SUNW,Sun-Fire-880
[22] CA_SUNW_PLAT SUNW,Sun-Fire-V210
[23] CA_SUNW_PLAT SUNW,Sun-Fire-V215
[24] CA_SUNW_PLAT SUNW,Sun-Fire-V240
[25] CA_SUNW_PLAT SUNW,Sun-Fire-V245
[26] CA_SUNW_PLAT SUNW,Sun-Fire-V250
[27] CA_SUNW_PLAT SUNW,Sun-Fire-V440
[28] CA_SUNW_PLAT SUNW,Sun-Fire-V445
[29] CA_SUNW_PLAT SUNW,Sun-Fire-V490
[30] CA_SUNW_PLAT SUNW,Sun-Fire-V890
[31] CA_SUNW_PLAT SUNW,Sun-Fire
[32] CA_SUNW_MACH sun4u
The present Elf{32|64}_Cap data structure is captured in a SHT_SUNW_CAP
section, .SUNW_cap. This data structure consists of one or more CA_SUNW_*
tags, and a terminating CA_SUNW_NULL (0) tag. This data structure, which
starts at .SUNW_cap[0] defines the capabilities of the object. This
"convention" will remain unchanged.
This project allows there to be multiple CA_SUNW_NULL terminated capabilities
groups. Again, .SUNW_cap[0] defines the capabilities of the object, but any
follow on groups allow for the definition of symbol capabilities.
A new SHT_SUNW_capinfo section is provided. This section is an array that
p
PSARC/2010/022 Linker-editors: Symbol Capabilities
On 01/20/10 01:38 PM, James Carlson wrote: > Rod Evans wrote: >> In other words, we can take the contents of all our libc_psr libraries and >> put them in one libc.so.1. Then we can then throw away the /platform >> symlinked psr libraries. > > Wicked cool. Any chance this (or some extension of it) could eventually > do in the loopback-mounted libc.so.1 on x86 as well, or is that too hard? Possibly. Although the amount of processing to instantiate a symbol capabilities instance is much less than the present "psr" library search, there's still some cost. The loop-back mount model, once instantiated, incurs no cost on each process that uses the library. There are ideas being floated in regards the loop-back mount model, as the draw-back of making the original libc "invisible" are well known. Whether symbol capabilities can replace this are unknown as yet. However, some of the extensions provided with this project (the expanded capabilities descriptors that provide for platform and machine names for example) are expected to be useful in any new mechanism. This model fits between the "psr" model and the loop-back mount model, and should provide a more flexible, and easier to create, model for general users to add symbol capabilities instances. But, there's more to come to address the loop-back mount model I'll be back. -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!
PSARC/2010/022 Linker-editors: Symbol Capabilities
I've just been pointed to the following mail, which can be found in the opensolaris-arc archives, but isn't in the PSARC mail log. Apologies for missing this, but I'm not subscribed to the opensolaris-arc alias. > Subject: Re: PSARC/2010/022 Linker-editors: Symbol Capabilities > From: "Richard L. Hamilton" > Date: Wed, 20 Jan 2010 22:07:13 -0800 (PST) > To: opensolaris-arc at opensolaris.org > > why not carry on to the logical conclusion, i.e. full fat binaries > (x86/amd64/sparcv7/sparcv9)? > -- This message posted from opensolaris.org Fat binaries, although brought up now and then, haven't triggered a large amount of interest. This project is more about the micro optimization of single class objects. -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!
PSARC/2008/309 - expunge synonyms.h
Joseph Kowalski wrote: > What is the commitment level to "libshim"? More relevantly, does this > get a man page? Does it get no man page, but some other documentation > (linker guide?)? Its kinda strange, because I can understand lots of > reasons to document it in unique ways, but I suspect it should be > documented somewhere. 0 at 0.so.1 only exists in ld.so.1(1) as far as I know. Perhaps something similar for Rogers library. NOTES ... The user compatibility library /usr/lib/0 at 0.so.1 provides a mechanism that establishes a value of 0 at location 0. Some applications exist that erroneously assume a null character pointer should be treated the same as a pointer to a null string. A segmentation violation occurs in these applica- tions when a null character pointer is accessed. If this library is added to such an application at runtime using LD_PRELOAD, the library provides an environment that is sym- pathetic to this errant behavior. However, the user compati- bility library is intended neither to enable the generation of such applications, nor to endorse this particular pro- gramming practice. -- Rod.
2007/474: new ldd(1) -w option
I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. 6594430/6595139 uncovered an issue where too many symbols had been reduced to locals within an application. This application, built with lex(1), should export a number of "yy*" interfaces so that libl.so can reference these entry points. However, the references in libl.so are all defined weak, and an unresolved weak reference results in no relocation error, and the value zero being written to the relocation offset. Bottom line, the lack of the required call back interfaces isn't being discovered by any tools we presently use to inspect binaries: oxpoly 432. ldd /usr/bin/genmsg libl.so.1 => /usr/lib/libl.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 This fast track introduced a new, -w, option to ldd(1): User Commands ldd(1) SYNOPSIS ldd [-d | -r] [-c] [-e envar] [-f] [-i] [-L] [-l] [-s] [-U | -u] [-v] [-w] filename... | ... ldd can also check the compatibility of filename with the shared objects filename uses. With each of the following options, ldd prints warnings for any unresolved symbol references that would occur when filename is loaded. -d Check immediate references. -r Check both immediate references and lazy references. -w Check for any unresolved weak symbol references.| Only one of the options -d or -r can be specified during any single invocation of ldd. The -w option can be combined | with either the -d option or the -r option. | ... Symbols that are used by relocations may be defined as weak | references. By default, if a weak symbol reference can not | be resolved, the relocation is ignored and a zero written to | the relocation offset. The -w, when used with either the -d | or the -r options, causes any unresolved relocation against | a weak symbol reference to be flagged as a relocation error. | With this option we can now observe unresolved weak references: oxpoly 434. ldd -rw /usr/bin/genmsg libl.so.1 => /usr/lib/libl.so.1 libc.so.1 => /lib/libc.so.1 symbol not found: __1cG__CrunMdo_exit_code6F_v_ (/usr/bin/genmsg) /platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 symbol not found: yyout (/usr/lib/libl.so.1) symbol not found: yyleng(/usr/lib/libl.so.1) symbol not found: yytext(/usr/lib/libl.so.1) symbol not found: yyfnd (/usr/lib/libl.so.1) symbol not found: yyprevious(/usr/lib/libl.so.1) symbol not found: yyextra (/usr/lib/libl.so.1) symbol not found: yylsp (/usr/lib/libl.so.1) symbol not found: yylstate (/usr/lib/libl.so.1) symbol not found: yyolsp(/usr/lib/libl.so.1) symbol not found: yywleng (/usr/lib/libl.so.1) symbol not found: yywtext (/usr/lib/libl.so.1) symbol not found: yylex (/usr/lib/libl.so.1) symbol not found: yyinput (/usr/lib/libl.so.1) symbol not found: yyunput (/usr/lib/libl.so.1) symbol not found: yyback(/usr/lib/libl.so.1) symbol not found: yywinput (/usr/lib/libl.so.1) symbol not found: yywunput (/usr/lib/libl.so.1) symbol not found: __tnf_probe_notify(/lib/libc.so.1) symbol not found: __tnf_probe_notify(/lib/libc.so.1) libm.so.2 => /lib/libm.so.2 Note, this option is also catching the weak reference of __Crun::do_exit_code() is the included crt, and thw two tnf references from libc. --- Release Binding: Patch/Micro ldd -w option Committed -- Rod.
2008/006: make ld(1) -z combreloc become default behavior
I'm sponsoring the following case for myself. This case qualifies for Architectural self-review, but I wish to record the following information. The link-editors -z combreloc flag combines individual relocation sections (like .rela.data and .rela.bss) into one relocation table .SUNW_reloc. This concatenation of the standard relocation tables allows ld(1) to sort all data relocations so that the symbol lookup cost, from ld.so.1(1), is minimized. The option has existed since Solaris 7 (4044285), and its use has been enforced for OSnet components via check_rtime. Linux took the same option, but went one step further and made the functionality the default behavior for gld as of version 2.13. Gld produces .rel.dyn sections, whereas ld produces .SUNW_reloc sections - however, the section names are never referenced, so their names aren't particularly meaningful. Gld also provides the additional -z nocombreloc option just in case. ld(1) should make -z combreloc the default behavior when creating a final object (ie., an executable or shared object). The -z combreloc option will still be recognized, but effectively ignored. A new -z nocombreloc option will be added to disable the relocation section concatenation. The ld(1) man page will be updated to add: Synopsis ld [-64] [-a | -r] [-b] [-Bdirect | nodirect] . [-z altexec64] [-z combreloc | nocombreloc ] [-z defs | nodefs] . Options The following options are supported: . -z combreloc | nocombreloc By default, the link-editor combines multiple relocation sections when building executables or shared objects. This section combination differs from relocatable objects, in which relocation sections are maintained in a one-to-one relationship with the sections to which the relocations must be applied. The -z nocombreloc option disables this merging of relocation sections, and preserves the one-to-one relationship found in the ori- ginal relocatable objects. The link-editor sorts the entries of data relocation sections by their symbol reference. This sorting reduces runtime symbol lookup. When multiple relocation sec- tions are combined, this sorting produces the least pos- sible relocation overhead when objects are loaded into memory, and speeds the runtime loading of dynamic objects. Historically, the individual relocation sections were carried over to any executable or shared object, and the -z combreloc option was required to enable the reloca- tion section merging previously described. Relocation section merging is now the default. The -z combreloc option is still accepted for the benefit of old build environments, but the option is unnecessary, and has no effect. Release Binding: Patch/Micro ld -znocombreloc option Committed -- Rod.
2008/006: make ld(1) -z combreloc become default behavior
Glenn Skinner wrote: > Date: Mon, 07 Jan 2008 11:09:56 -0800 > From: Rod Evans > Subject: 2008/006: make ld(1) -z combreloc become default behavior > > ... > ld(1) should make -z combreloc the default behavior when creating a > final object (ie., an executable or shared object). The -z combreloc > option will still be recognized, but effectively ignored. A new > -z nocombreloc option will be added to disable the relocation section > concatenation. > > Under what circumstances might one wish to use the old behavior? I have no idea why anyone would want to use the old behavior. The relocation tables within dynamic objects have always been concatenated together, and are read by ld.so.1 as one contiguous table. Creating a single table doesn't change how ld.so.1 reads it, it just allows the table to be better optimized (sorted). But, like so many historic artifacts, there's always the possibly that someone, somewhere would like the old layout. -z nocombreloc provides this back door - plus, gld provides the option too, so in a way we're conforming with gld use. > What is the compatibility impact of switching this default? None that we're aware of. We've used the option ourself throughout the OS for years, and have advised others to do so too. As the gld folks have made it their default, I suspect they've found no compatibility issues either. Given this background, making the behavior default rather than trying to keep asking developers to use -z combreloc will help the startup performance of all dynamic objects (a bit). -- Rod.
2008/006: make ld(1) -z combreloc become default behavior
Joseph Kowalski wrote: > So, just for completeness, please add a explicit "release binding" to the > case. It seems that the above provides the rationale for a "Patch Binding" > while changing defaults is usually something reserved for "Minor Binding". It's already stated: Release Binding: Patch/Micro ld -znocombreloc option Committed -- Rod
2007/643: New libmvec interfaces
I'm sponsoring the following case for Douglas Priest. This case qualifies for Architectural self-review, but we wish to record the following information. --- This project adds the following entry points to libmvec, specifically both the (SPARC-only) libmvec.a shipped with the compilers and the (SPARC/x86/x64) libmvec.so.1 in Nevada. (public entry points) vsinpi_ vcospi_ vsincospi_ vsinpif_ vcospif_ vsincospif_ (internal entry points, used only by the compiler) __vsinpi __vsinpi_ __vcospi __vcospi_ __vsincospi __vsincospi_ __vsinpif __vsinpif_ __vcospif __vcospif_ __vsincospif __vsincospif_ These routines provide vector trigonometric functions with the argument implicitly scaled by pi, e.g., vsinpi_ computes sin(pi*x) for each x in the argument vector. A draft man page for vsinpi_/vsinpif_ as well as one for libmvec as a whole appear below. Similar pages for the other functions in libmvec will be added to Nevada. References: LSARC 1997/131 xvector LSARC 1998/323 libmvec additions LSARC 2001/774 Vector Square Root Functions LSARC 2002/564 Vector Reciprocal Hypot Functions LSARC 2003/737 Shared Vector Math Library libmvec.so.1 --- Vector Math Library Functions vsinpi(3MVEC) NAME vsinpi_, vsinpif_ - vector sinpi functions SYNOPSIS cc [ flag... ] file... -lmvec [ library... ] void vsinpi_(int *n, double * restrict x, int *stridex, dou- ble * restrict y, int *stridey); void vsinpif_(int *n, float * restrict x, int *stridex, float * restrict y, int *stridey); DESCRIPTION These routines evaluate the sinpi function, defined by sinpi(x) := sin(pi * x), for an entire vector of values at once. The first parameter specifies the number of values to compute. Subsequent parameters specify the argument and re- sult vectors. Each vector is described by a pointer to the first element and a stride, which is the increment between successive elements. Specifically, vsinpi_(n, x, sx, y, sy) computes y[i * *sy] = sinpi(x[i * *sx]) for each i = 0, 1, ..., *n - 1. vsinpif_ performs the same computation for single precision data. USAGE The element count *n must be greater than zero. The strides for the argument and result arrays may be arbitrary inte- gers, but the arrays themselves must not be the same or overlap. (A zero stride effectively collapses an entire vector into a single element. A negative stride causes a vector to be accessed in descending memory order, but note that the corresponding pointer must still point to the first element of the vector to be used; if the stride is negative, this will be the highest-addressed element in memory. This convention differs from the Level 1 BLAS, in which array parameters always refer to the lowest-addressed element in memory even when negative increments are used.) These functions assume that the default round-to-nearest rounding direction mode is in effect. On x86, these func- tions also assume that the default round-to-64-bit rounding precision mode is in effect. The result of calling a vector function with a non-default rounding mode in effect is unde- fined. These functions handle special cases and exceptions in the spirit of IEEE 754. In particular, - sinpi(NaN) is NaN, - sinpi(+/-0) is ?0, - sinpi(+/-Inf) is NaN, and an invalid operation exception is raised. An application wanting to check for exceptions should call feclearexcept(FE_ALL_EXCEPT) before calling these functions. On return, if fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW) is non-zero, an exception has been raised. The application can then examine the result or argument vectors for exceptional values. Note that some vector functions may raise the inexact exception even if all elements of the argument array are such that the numerical results are exact. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Interface Stability | Committed | |_|_| | MT-Level| MT-Safe | |_|_| SEE ALSO trig_sun(3M), feclearexcept(3M), fetestexcept(3M), attri- butes(5) ---
2007/559: new symbol visibilities - EXPORTED, SINGLETON, and ELIMINATE
Just for the record, there's a cut-and-paste error: > As this is a "public" ELF field, the proposal was passed around several > > ELF vendors. See: > > > > > > http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc1566616 The link should be: http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc15666164 Bug report 660245 has the correct link. -- Rod.
2007/559: new symbol visibilities - EXPORTED, SINGLETON, and ELIMINATE
Nicolas Williams wrote: > A few questions: > >Can one interpose on singleton symbols using LD_PRELOAD? I assume >yes, or at most that the interposers in the pre-loaded object must be >labelled singleton as well. An interposer can win, it still provides the *first* symbol. >Will dlsym(RTLD_NEXT, ) return the next symbol? Or >the one bound symbol (it is a singleton, after all)? > >If multiple objects define the same singleton symbol, will dlsym() >called with a handle for each of those objects resolve the same >symbol to the first definition, or to each object's version? It doesn't matter how a symbol is located, via relocation of via dlsym() (or what flag you use in dlsym()), the effect should be that same, in that all references get bound to one definition. >Presumably libraries designed so that multiple versions can be >present in one process (I think that's feasible, with some >constraints) must not use singleton symbols. Correct. -- Rod.
