Question regarding platform-bits in ld.so.cache

Question regarding platform-bits in ld.so.cache

[Stefan Liebler]

Hi,

according to the NEWS entry for glibc 2.37:
glibc commit "Add NEWS entry for legacy hwcaps removal"
https://sourceware.org/git/?p=glibc.git;a=commit;h=78d9a1620b840deb0880686e4159eaf70708866a
The dynamic linker no longer no longer loads shared objects from ... or
the subdirectory that corresponds to the AT_PLATFORM system name ...


But ld.so can still handle ld.so.cache-entries with the platform bits,
see elf/dl-cache.c: search_cache():
  /* Used by the HWCAP check in the struct file_entry_new case.  */
  uint64_t platform = _dl_string_platform (GLRO (dl_platform));
  if (platform != (uint64_t) -1)
    platform = 1ULL << platform;
  uint64_t hwcap_mask = TUNABLE_GET (glibc, cpu, hwcap_mask, uint64_t,
NULL);
#define _DL_HWCAP_TLS_MASK (1LL << 63)
  uint64_t hwcap_exclude = ~((GLRO (dl_hwcap) & hwcap_mask)
                             | _DL_HWCAP_PLATFORM | _DL_HWCAP_TLS_MASK);
...
                  if ((libnew->hwcap & hwcap_exclude) && !named_hwcap)
                     continue;
                  if (_DL_PLATFORMS_COUNT
                       && (libnew->hwcap & _DL_HWCAP_PLATFORM) != 0
                       && ((libnew->hwcap & _DL_HWCAP_PLATFORM)
                           != platform))
                     continue;


For the ld.so.cache platform-bits mechanism, a platform needs
_dl_string_platform() returning != -1, _DL_PLATFORMS_COUNT > 0 and
_DL_HWCAP_PLATFORM != 0.
Thus those architectures are using this mechanism:
powerpc, s390, mips, alpha, csky and x86

NOTE: powerpc is using _dl_string_platform() also here:
sysdeps/powerpc/hwcapinfo.c:37:  __tcb.at_platform = _dl_string_platform
(GLRO (dl_platform));
=> Within exported symbol __parse_hwcap_and_convert_at_platform.
sysdeps/powerpc/test-get_hwcap.c:123:  at_platform = _dl_string_platform
(at_platform_string);


The legacy hwcaps support was removed with those commits:
- "elf: Remove legacy hwcaps support from the dynamic loader"
https://sourceware.org/git/?p=glibc.git;a=commit;h=6099908fb84debee4c3bcb05d88769410c2aecd1
- "elf: Remove legacy hwcaps support from ldconfig" (glibc 2.37)
https://sourceware.org/git/?p=glibc.git;a=commit;h=b78ff5a25dc8ba9d8c6df10bb0a533254bdd193f

The latter one also removed creating ld.so.cache-entries with the
platform-bits.


Is there a plan to also remove the usage in
elf/dl-cache.c:search_cache() and perhaps also _dl_string_platform(),
_DL_PLATFORMS_COUNT and _DL_HWCAP_PLATFORM at all?

Or does it make sense to at least not extend those anymore and perhaps
add a comment that ldconfig does not create such entries anymore, but
ld.so can still handle old ones?

Bye,
Stefan

Re: Question regarding platform-bits in ld.so.cache

[Florian Weimer]

* Stefan Liebler:

> Is there a plan to also remove the usage in
> elf/dl-cache.c:search_cache() and perhaps also _dl_string_platform(),
> _DL_PLATFORMS_COUNT and _DL_HWCAP_PLATFORM at all?

I think we should remove all this, it's just an oversight on my part
that it's still there (certainly for the elf/dl-cache.c parts).

Thanks,
Florian

Re: Question regarding platform-bits in ld.so.cache

[Stefan Liebler]

On 17.05.24 15:14, Florian Weimer wrote:
> * Stefan Liebler:
> 
>> Is there a plan to also remove the usage in
>> elf/dl-cache.c:search_cache() and perhaps also _dl_string_platform(),
>> _DL_PLATFORMS_COUNT and _DL_HWCAP_PLATFORM at all?
> 
> I think we should remove all this, it's just an oversight on my part
> that it's still there (certainly for the elf/dl-cache.c parts).
> 
Thus this means that all entries which are no named/extension ones where
libnew->hwcap!=0 should be skipped?

Then the tls, legacy-platform-bits and legacy-hwcap-entries are skipped.
Then the tunable hwcap_mask/LD_HWCAP_MASK is also not needed anymore?


> Thanks,
> Florian
> 

Re: Question regarding platform-bits in ld.so.cache

[Florian Weimer]

* Stefan Liebler:

> On 17.05.24 15:14, Florian Weimer wrote:
>> * Stefan Liebler:
>> 
>>> Is there a plan to also remove the usage in
>>> elf/dl-cache.c:search_cache() and perhaps also _dl_string_platform(),
>>> _DL_PLATFORMS_COUNT and _DL_HWCAP_PLATFORM at all?
>> 
>> I think we should remove all this, it's just an oversight on my part
>> that it's still there (certainly for the elf/dl-cache.c parts).

> Thus this means that all entries which are no named/extension ones where
> libnew->hwcap!=0 should be skipped?

Yes, based on my recollection of the code, that would be the right way
to simplify the code.

> Then the tls, legacy-platform-bits and legacy-hwcap-entries are skipped.
> Then the tunable hwcap_mask/LD_HWCAP_MASK is also not needed anymore?

I think we still use that to alter the result of getauxval (AT_HWCAP),
affecting the results of IFUNC resolvers within and outside of glibc
on some architectures.

Thanks,
Florian

Re: Question regarding platform-bits in ld.so.cache

[Peter Bergner]

On 5/17/24 8:06 AM, Stefan Liebler wrote:
> NOTE: powerpc is using _dl_string_platform() also here:
> sysdeps/powerpc/hwcapinfo.c:37:  __tcb.at_platform = _dl_string_platform
> (GLRO (dl_platform));
> => Within exported symbol __parse_hwcap_and_convert_at_platform.
> sysdeps/powerpc/test-get_hwcap.c:123:  at_platform = _dl_string_platform
> (at_platform_string);

On powerpc, we replicate the AT_PLATFORM value (actually a unique integer
that maps to a specific AT_PLATFORM string) and our AT_HWCAP{,2,3,4} masks
in our TCB for access from our __builtin_cpu_is() and __builtin_cpu_supports()
built-in functions.


Peter