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

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

Adding hwcap support to ldconfig/ld.so.cache



Hi libc-hacker,

The support for hwcaps in the dynamic linker is not working completly
since the cache file doesn't handle it.  

Here's an example: You can put a library compiled with mmx support on
ix86 in /lib/mmx and it should be used instead of the one in /lib if
your system support mmx.  This works only if the library is *not* in the
cache (check the output of LD_DEBUG=libs LD_PRELOAD=nonexisting ls).

I'd like to add hwcaps support to the cache.  Unfortunatly I couldn't
find a clean way to extend the current cache file (if you see one,
please tell me).  For compatibility with libc5, I don't want to change
the format.  Therefore I'm proposing to add a new file
"ld.so.ncache".  ldconfig will create both files but glibc 2.2 will
only read the new file.

I'm considering two extend the old format as follows:

This is an entry for a single library:
struct file_entry
{
  int flags;			/* This is 1 for an ELF library.  */
  unsigned int filename, path;	/* String table indices.  */
  unsigned long hwcap;		/* Hwcap entry.  */
};

The hwcap entry is new.  I'm also considering to change the semantics
for the strings: We currently use a filename and the complete path
including the filename, e.g. we save "libc.so.6" and "/lib/libc.so.6,
(stored as indices into a string table).  To save space (the file is
mapped into each binary and read at every program start), I'd prefer
to only store the filename and the path without it, e.g. "libc.so.6"
and "/lib".  Since we only have a small number of paths, this should
reduce the size significantly.  The only disadvandge would be that
the dynamic linker needs to construct the complete pathname from these
two components.  I'll try to test both methods and compare file size.

Should we add some unused entries to the struct?  Is anybody in need
of some more entries?

The cache file itself should be easy to extend (if not, please speak
up).  I therefore added some unused entries and also one field to
record the size of the string table.  Since the string table comes
directly after the file_entry array, it should now be possible to add
further tables after the string table.

Here's the structure:
#define CACHEMAGIC_NEW "glibc-ld.so.ncache"
#define VERSION "1.0"
struct cache_file
{
  char magic[sizeof CACHEMAGIC_NEW - 1];
  char version[sizeof VERSION - 1];
  unsigned int nlibs;		/* Number of entries.  */
  unsigned int len_strings;	/* Size of string table. */
  unsigned int unused[4];	/* Leave space for future extensions.  */
  struct file_entry libs[0];	/* Entries describing libraries.  */
  /* After this the string table of size len_strings is found.  */
};

I've also added a version number which can be easily incremented.
Since we now have ldconfig as part of glibc, we could now even make
incompatible changes.

Roland, Hurd's dynamic linker is currently not using the cache.  Do
you want to leave it this way, or would you like to use this feature
now?

Could you please send me your comments on this?  I'd like to go ahead
and implement this soonish (in fact I've already started adding this
to ldconfig).

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

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