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] |
>>>>> 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |