This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: comment on today's changes
On Mon, Dec 28, 1998 at 06:55:37PM -0800, Ulrich Drepper wrote:
> ralf@uni-koblenz.de writes:
>
> > Are you speaking of Mips' Quickload feature, originally implemented for
> > RISC/os? I've got docs and I think they're quite complete, if still of
> > interest.
>
> Yes, this is one of the improvements. I think we figured out how it
> works but if you have some docs I wouldn't mind getting them
> nevertheless.
Ok, here is what the MIPS ABI has to say about Quickstart. Even though the
MIPS ABI is not the best thing since invention of Swiss Choccolate it would
be nice if the glibc implementation would be ABI compliant.
There are newer versions of the MIPS ABI available on www.mipsabi.org but I
cannot remember them mentioning Quickstart. But I'm not shure. I'll dig
out the RISC/os documentation later and check if it there is additional
information. You may also want to dig through the online documentation
of IRIX and on www.sgi.com.
Ralf
------------------------------------------------------------------------------
Dynamic Linking
[...]
Ordering
To take advantage of Quickstart functionality, the .dynsym and the .rel.dyn
sections must obey ordering constraints. The GOT-mapped portion of the
.dynsym section must be ordered on increasing values in the st_value field.
This requires that the .got section have the same order, since it must
correspond to the .dynsym section.
The .rel.dyn section must have all local entries first followed by the
external entries. Within these sub-sections, the entries must be ordered
by symbol index.
Quickstart
The MIPS supplement to the ABI defines two sections which are useful for
faster start-up of programs when the programs have been linked with dynamic
shared objects. The group of structures defined in these sections allow the
dynamic linker to operate more efficiently than when these sections are not
present. These additional sections are also used for more complete dynamic
shared object version control.
An ABI compliant system can ignore the sections defined here, but if it
supports of of these sections, it must support both of them. If you relink
or relocate the object file on secondary storage and cannot process these
sections, you must delete them.
Shared Object List
A shard objet list section is an array of structures that contain
information about the various dynamic shared objects used to statically link
this object file. Eah separate shared object used generates one Elf32_Lib
array element. The shared object list is used for more complete shared
object version control.
--------------------------------------------------------------------------
Figure 5-12: Shared Object Informatin Structure
typedef struct {
Elf32_Word l_name;
Elf32_Word l_time_stamp;
Elf32_Word l_checksum;
Elf32_Word l_version;
Elf32_Word l_flags;
} Elf32_Lib;
-------------------------------------------------------------------------
l_name This member specifies the name of a shard object. Its value is a
string table index. This name can be a trailing component of the
path to be used with RPATH + LD_LIBRARY or a name containing '/'s,
which is relative to '.', or it can be a full pathname.
l_time_stamp This members's value is a 32 bit time stamp. It can be
combined with the l_checksum value and the l_version string to form
an unique id for this shared object.
l_checksum This member's value is the sum of all externally visable
symbol's string names and common sizes.
l_version Thsi member specifies the interface version. Its value is
a string table index. The interface version is a single string
containing no colongs (:). It is compared agains a colon separated
string of versions pointed to by a dynamic section entry of the
shared object. Shared objects with matching names are considered
if the interface version strings are deemed incompatible. An index
value of zero means no version string is specified.
flags This is a set of 1 bit flags. Flag definitions appear below.
------------------------------------------------------------------------
Figure 5-13: Library Flags, l_flags
Name Value Meaning
--------------------------------------------------------------------
LL_EXACT_MATCH 0x00000001 require exact match
LL_IGNORE_INT_VER 0x00000002 ignore interface version
--------------------------------------------------------------------
------------------------------------------------------------------------
LL_EXACT_MATCH At run-time use a unique id composed of the l_time_stamp,
l_checksum, and l_version fields to demand that the run-time dynamic
shared library match exactly the sared library used at static link
time.
LL_IGNORE_INT_VER
At run-time, ignore any version incompatibilites between the dynamic
shared library and the library used at static link time.
Normally, if neither LL_EXACT_MATH nor LL_IGNORE_INT_VER bits are set,
the dynamic linker requires that the version of the dynamic shared library
match at least one of the colon separated version strings indexed by the
l_version string table index.
Conflict Section
The .conflict section is an array of indexes into the .dynsym section. Each
index identifies a symbol whose attributes conflict with a shared object on
which it depend, either in type or size such that this definition will
preempt the shared object's defintion. The dependent shared object is
identified at static link time.
------------------------------------------------------------------------
Figure 5-14: Conflict Section
typedef Elf32_Addr Elf32_Conflict
------------------------------------------------------------------------