This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] elf: Update GNU_PROPERTY_X86_XXX macros [BZ #23797]
- From: Mark Wielaard <mark at klomp dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, libc-alpha at sourceware dot org
- Date: Wed, 24 Oct 2018 13:03:51 +0200
- Subject: Re: [PATCH] elf: Update GNU_PROPERTY_X86_XXX macros [BZ #23797]
- References: <20181019224743.9457-1-hjl.tools@gmail.com>
Hi,
Some questions about how to interpret the new constant values vs the
old ones. I am not sure I understand how this is fully backwards
compatible.
On Fri, 2018-10-19 at 15:47 -0700, H.J. Lu wrote:
> GNU_PROPERTY_X86_FEATURE_1_AND is unchanged. GNU_PROPERTY_X86_ISA_1_USED
> and GNU_PROPERTY_X86_FEATURE_2_USED are redefined to better support
> targeted processors since GNU_PROPERTY_X86_ISA_1_?86 aren't isn't very
> useful. A new set of GNU_PROPERTY_X86_ISA_1_XXX bits are defined. The
> previous GNU_PROPERTY_X86_ISA_1_XXX macros are removed.
So GNU_PROPERTY_X86_FEATURE_1_AND is kept at the same constant value,
but now falls into the GNU_PROPERTY_X86_UINT32_AND_XXX range which has
specific semantics for how linkers combine the note data. Isn't this a
backwards compatible issue? There is no guarantee the note data was
constructed by a linker that knows about this, but there is no way to
detect that?
GNU_PROPERTY_X86_ISA_1_USED and GNU_PROPERTY_X86_FEATURE_2_USED are
renumbered. And the the GNU_PROPERTY_X86_ISA_1_XXX macros are renamed,
but some are kept the same with new constant values. Were the old
constants/names not used at all?
> +/* Set by linker to indicate that the property is valid. */
> +#define GNU_PROPERTY_X86_UINT32_VALID (1U << 31)
This isn't mentioned in your commit message, nor is it mentioned in the
ChangeLog entry. Should it be added? And if so, how does it interact
with the interpretation of GNU_PROPERTY_X86_FEATURE_1_AND generated by
older linkers or interpreted by older loaders (does it have to be
checked by newer loaders?)
Thanks,
Mark