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] |
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] |