public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug dynamic-link/25938] New: ld.so.cache should store meaning of hwcap mask bits
@ 2020-05-07 10:24 fw at deneb dot enyo.de
2020-12-04 8:52 ` [Bug dynamic-link/25938] " fweimer at redhat dot com
0 siblings, 1 reply; 2+ messages in thread
From: fw at deneb dot enyo.de @ 2020-05-07 10:24 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=25938
Bug ID: 25938
Summary: ld.so.cache should store meaning of hwcap mask bits
Product: glibc
Version: unspecified
Status: NEW
Severity: minor
Priority: P3
Component: dynamic-link
Assignee: unassigned at sourceware dot org
Reporter: fw at deneb dot enyo.de
Target Milestone: ---
Flags: security-
The meaning of the bits depends on the glibc version: _DL_FIRST_EXTRA depends
on _DL_FIRST_PLATFORM and _DL_PLATFORMS_COUNT, and the latter increases if more
platform subdirectories are added (e.g., "power9").
This does not appear to be a significant issue today because the
_DL_FIRST_EXTRA mechanism was only ever used for the i686 nosegneg bit, and on
i686, _DL_FIRST_EXTRA has been unchanged for a long time.
The always-set bit for the "tls" subdirectory is put by ldconfig at the MSB of
the 64-bit hwcap word, so its position is already constant.
However, if we ever want to reuse hwcap bits for different CPU features, the
cache needs to contain additional information about the meaning of the bits.
One way to express this mean is to list the subdirectory names the bits
correspond to.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug dynamic-link/25938] ld.so.cache should store meaning of hwcap mask bits
2020-05-07 10:24 [Bug dynamic-link/25938] New: ld.so.cache should store meaning of hwcap mask bits fw at deneb dot enyo.de
@ 2020-12-04 8:52 ` fweimer at redhat dot com
0 siblings, 0 replies; 2+ messages in thread
From: fweimer at redhat dot com @ 2020-12-04 8:52 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=25938
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2.33
CC| |fweimer at redhat dot com
Status|NEW |RESOLVED
Resolution|--- |FIXED
Assignee|unassigned at sourceware dot org |fweimer at redhat dot com
--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
More or less fixed in glibc 2.33 by a new mechanism:
commit b44ac4f4c7a8bbe5eaa2701aa9452eaf2c96e1dd
Author: Florian Weimer <fweimer@redhat.com>
Date: Fri Dec 4 09:13:43 2020 +0100
elf: Process glibc-hwcaps subdirectories in ldconfig
Libraries from these subdirectories are added to the cache
with a special hwcap bit DL_CACHE_HWCAP_EXTENSION, so that
they are ignored by older dynamic loaders.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit 600d9e0c87940da9b0fdeff492bf888df852d40c
Author: Florian Weimer <fweimer@redhat.com>
Date: Fri Dec 4 09:13:43 2020 +0100
elf: Add glibc-hwcaps subdirectory support to ld.so cache processing
This recognizes the DL_CACHE_HWCAP_EXTENSION flag in cache entries,
and picks the supported cache entry with the highest priority.
The elf/tst-glibc-hwcaps-prepend-cache test documents a non-desired
aspect of the current cache implementation: If the cache selects a DSO
that does not exist on disk, _dl_map_object falls back to open_path,
which may or may not find an alternative implementation. This is an
existing limitation that also applies to the legacy hwcaps processing
for ld.so.cache.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-12-04 8:52 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-07 10:24 [Bug dynamic-link/25938] New: ld.so.cache should store meaning of hwcap mask bits fw at deneb dot enyo.de
2020-12-04 8:52 ` [Bug dynamic-link/25938] " fweimer at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).