[PATCH v5 2/4] Add system-wide tunables: cache ld.so.cache

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Fri Feb 27 19:53:38 GMT 2026



On 27/02/26 16:38, DJ Delorie wrote:
> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
>> I agree with Yury here that we need to add some tests, at least some
>> minimal one that stress the ld.so.cache reload (which is not the usual
>> scenario).  I would suggest add test-containts tests that:
> 
> Yup, I was thinking the same thing.  One test should be able to test
> both good->bad and bad->good as well as changes to paths.
> 
>>     1.3. If not modifying the ld.so.cache contents keep the same
>>          contents.
> 
> I assume this just requires doing two dlopen()'s back to back and making
> sure they both work?

Yeap, I double check next week if this scenario cover everything.

> 
>>> +  static int copy_old_time = 0;
>>
>> Maybe use bool here?
> 
> Can do.
> 
>>> +  /* At this point, NEW_CACHE_FILE_TIME is valid as well as
>>> +     CACHE_FILE_TIME, so we compare them.  We list fields in the order
>>> +     they're most likely to be different in.  */
>>> +  return ((new_cache_file_time.st_mtime != cache_file_time.st_mtime)
>>> +	  || (new_cache_file_time.st_ino != cache_file_time.st_ino)
>>> +	  || (new_cache_file_time.st_size != cache_file_time.st_size)
>>> +	  || (new_cache_file_time.st_dev != cache_file_time.st_dev)
>>> +	   );
>>
>> Maybe only keep the required fields, instead of while stat struct?
>> If we use a struct the test could optimized in bulk by the compiler.
> 
> Done.  I used this syntax to avoid having to "know" what the struct stat
> field types are:
> 
> static struct {
>   typeof (struct __stat64_t64.st_mtime) mtime;
>   typeof (struct __stat64_t64.st_ino) ino;
>   typeof (struct __stat64_t64.st_size) size;
>   typeof (struct __stat64_t64.st_dev) dev;
> } cache_file_time, new_cache_file_time;

Neat, it should work.



More information about the Libc-alpha mailing list