From: Florian Weimer <fweimer@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: "H.J. Lu via Libc-alpha" <libc-alpha@sourceware.org>
Subject: Re: V5 [PATCH 2/2] ldconfig/x86: Add ISA level check to glibc-hwcaps
Date: Tue, 08 Dec 2020 15:18:33 +0100 [thread overview]
Message-ID: <87wnxscreu.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <CAMe9rOqiXan=2+8Kc2F0rbO2gEs=FjaHctzL7b=gYX8BLtU=Fg@mail.gmail.com> (H. J. Lu's message of "Tue, 8 Dec 2020 06:10:38 -0800")
* H. J. Lu:
> On Tue, Dec 8, 2020 at 5:32 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu:
>>
>> > On Mon, Dec 7, 2020 at 2:00 AM Florian Weimer <fweimer@redhat.com> wrote:
>> >>
>> >> * H. J. Lu via Libc-alpha:
>> >>
>> >> > Add ISA level check to detect misplaced shared objects with incompatible
>> >> > ISA level requirement in glibc-hwcaps subdirectories:
>> >> >
>> >> > /sbin/ldconfig: /usr/lib64/glibc-hwcaps/x86-64-v2/libx86-64-isa-level.so: skipped, ISA level mismatch (x86-64-v4 > x86-64-v2)
>> >>
>> >> I think this is conceptually the wrong approach. ldconfig should copy
>> >> the notes into the cache (and aux cache), and ld.so should skip cache
>> >> contents that doesn't match the run-time requirements during load. Then
>> >> directory place does not matter that much anymore.
>> >
>> > Do we have space in cache for it?
>>
>> We have an extension mechanism. The relevant struct looks like this:
>>
>> struct file_entry_new
>> {
>> int32_t flags; /* This is 1 for an ELF library. */
>> uint32_t key, value; /* String table indices. */
>> uint32_t osversion; /* Required OS version. */
>> uint64_t hwcap; /* Hwcap entry. */
>> };
>>
>> We can set a previously-unused bit hwcap to hide entries from current
>> ld.so. This way, we can repurpose other hwcap bits, osversion, even
>> flags. We could put an index there into a array of (property) notes,
>> and use deduplication to share identical notes from different shared
>> objects.
>>
>> In essence, this is how the glibc-hwcaps subdirectory mechanism achieves
>> backwards-compatibility.
>>
>
> For each file entry for a shared object, the hwcap field has been used by
> DL_CACHE_HWCAP_EXTENSION for glibc-hwcaps. Are you suggesting
> to add another file entry for the same shared object to store ISA level
> requirement?
It's a 64-bit field. We do this:
/* This bit in the hwcap field of struct file_entry_new indicates that
the lower 32 bits contain an index into the
cache_extension_tag_glibc_hwcaps section. Older glibc versions do
not know about this HWCAP bit, so they will ignore these
entries. */
#define DL_CACHE_HWCAP_EXTENSION (1ULL << 62)
/* Return true if the ENTRY->hwcap value indicates that
DL_CACHE_HWCAP_EXTENSION is used. */
static inline bool
dl_cache_hwcap_extension (struct file_entry_new *entry)
{
/* If DL_CACHE_HWCAP_EXTENSION is set, but other bits as well, this
is a different kind of extension. */
return (entry->hwcap >> 32) == (DL_CACHE_HWCAP_EXTENSION >> 32);
}
So we can use a different bit pattern involving DL_CACHE_HWCAP_EXTENSION
to express something else. In particular, only the lower 32 bits are
currently used as an index.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
next prev parent reply other threads:[~2020-12-08 14:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-06 14:49 V5 [PATCH 0/2] x86: Support GNU_PROPERTY_X86_ISA_1_NEEDED marker [BZ #26717] H.J. Lu
2020-12-06 14:49 ` V5 [PATCH 1/2] x86: Support GNU_PROPERTY_X86_ISA_1_V[234] " H.J. Lu
2021-01-06 12:00 ` Adhemerval Zanella
2021-01-06 17:11 ` V6 " H.J. Lu
2021-01-07 20:09 ` Adhemerval Zanella
2021-01-07 20:58 ` H.J. Lu
2021-01-18 11:17 ` Florian Weimer
2021-01-18 13:49 ` H.J. Lu
2021-01-18 15:15 ` Florian Weimer
2020-12-06 14:49 ` V5 [PATCH 2/2] ldconfig/x86: Add ISA level check to glibc-hwcaps H.J. Lu
2020-12-07 10:00 ` Florian Weimer
2020-12-08 13:25 ` H.J. Lu
2020-12-08 13:31 ` Florian Weimer
2020-12-08 14:10 ` H.J. Lu
2020-12-08 14:18 ` Florian Weimer [this message]
2020-12-08 14:23 ` H.J. Lu
2020-12-08 15:15 ` Florian Weimer
2020-12-08 15:31 ` H.J. Lu
2020-12-09 3:27 ` [PATCH] ldconfig/x86: Store ISA level in cache and aux cache H.J. Lu
2021-01-12 16:25 ` Adhemerval Zanella
2021-01-12 23:32 ` V2 " H.J. Lu
2021-01-13 13:47 ` Adhemerval Zanella
2021-01-13 14:12 ` H.J. Lu
2021-01-28 20:20 ` Florian Weimer
2021-01-28 20:43 ` H.J. Lu
2021-01-29 8:56 ` Florian Weimer
2021-01-29 12:44 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wnxscreu.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).