This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

  ------------------------------------------------------------------------


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]