ldconfig hwcap rewrite
Andreas Jaeger
aj@suse.de
Sat May 6 06:59:00 GMT 2000
>>>>> Ulrich Drepper writes:
Uli> Andreas Jaeger <aj@suse.de> writes:
>> What's the best way to check for hwcaps? The current way which isn't
>> either clever nor very good is to use:
>> if ((entry[idx].hwcap & _dl_hwcap) > _dl_hwcap)
>> for stepping over libraries and using the first one that fits. But
>> there might be a number of libraries which fit. Is there a way to
>> order them? Currently thw hwcaps are ordered to their numerical value.
>> I'll also try to use HWCAP_IMPORTANT.
Uli> I think if you look at HWCAP_IMPORTANT and then at the numerical
Uli> values, that's enough. The user has still the option to remove one of
Uli> the objects.
I've had a look at the code in dl-sysdeps.c and will try to handle it
in a similar way. ldconfig will only look at HWCAP_IMPORTANT and
ignore all other hwcaps.
Uli> I'm still not sure whether you understood the potential I'm seeing.
Uli> Look at this example:
Uli> lib1
Uli> lib2
Uli> lib3 hwcap=7
Uli> lib3 hwcap=6
Uli> lib3 hwcap=4
Uli> lib3 hwcap=3
Uli> lib3 hwcap=2
Uli> You are searching for lib3 and hwcap is 7. Searching will immediately
Uli> find the entry "lib3 hwcap=6" and starts searching from there. The
Uli> entry with hwcap=7 is not found. There are many related problem which
It is found, there's this piece of code in dl-cache.c:
/* There might be entries with this name before the one we \
found. So we have to find the beginning. */ \
while (middle > 0 \
/* Make sure string table indices are not bogus before \
using them. */ \
&& _dl_cache_verify_ptr (cache->libs[middle - 1].key) \
/* Actually compare the entry. */ \
&& (_dl_cache_libcmp (name, \
cache_data + cache->libs[middle - 1].key) \
== 0)) \
--middle; \
Therefore we should always find the first entry (this is old code,
nothing I've added, I just reused it).
Uli> all involve the that you cannot be sure that an entry matching exactly
Uli> the search criteria is available. I think the data structure must be
Uli> something like this:
Uli> [0] lib1 [0]
Uli> [1] lib2 [1]
Uli> [2] lib3 hwcap=7 [2]
Uli> [3] lib3 hwcap=6 [2]
Uli> [4] lib3 hwcap=4 [2]
Uli> [5] lib3 hwcap=3 [2]
Uli> [6] lib3 hwcap=2 [2]
Uli> The first column is the inde of the entry in the table and does not
Uli> have to be stored. The new last column specifies the first entry with
Uli> the same name. Then you can simply start seaching incrementally there.
I could easily add this as an optimization
Uli> Again, I'm not sure whether this is really a problem with your code.
Uli> I just have seen binary search and without such helper structures it
Uli> cannot be used.
Thanks for the long explanation. Now I do know what you're after -
and I'm convinced the code is fine;-). I'll document this a bit
better.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
More information about the Libc-hacker
mailing list