This is the mail archive of the 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]

Re: ldconfig hwcap rewrite

>>>>> Ulrich Drepper writes:

Uli> Andreas Jaeger <> 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

 Andreas Jaeger
  SuSE Labs

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