Compatibility issues around <sys/platform/x86.h>

[H.J. Lu]

On Tue, Dec 22, 2020 at 4:43 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 22/12/2020 08:42, H.J. Lu wrote:
> > On Mon, Dec 21, 2020 at 9:16 AM Adhemerval Zanella via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> >>
> >>
> >>
> >> On 21/12/2020 14:05, H.J. Lu via Libc-alpha wrote:
> >>> On Mon, Dec 21, 2020 at 5:00 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>>>
> >>>> I finally had some time to review the <sys/platform/x86.h> interface.
> >>>>
> >>>> I have two major concerns:
> >>>>
> >>>> (a) Placement of struct cpu_features in _rtld_global_ro
> >>>>
> >>>> This means that backporting new feature support changes the internal
> >>>> GLIBC_PRIVATE ABI. Consequently, there's a race condition during
> >>>> in-place updates where loading binaries can fail in obscure ways, due to
> >>>> the change in _rtld_global_ro offsets.  We should really avoid this.
> >>>
> >>> This applies to all members in _rtld_global_ro.
> >>
> >> Couldn't it be mitigated by adding member solely at the end of the struct
> >> and making sure the backport uses the same offset?
> >
> > What if we need to extend a member in the middle?
> >
>
> My question also extends if we would need to do so. Do we plan to extend
> the cpu_features indefinitely or can we pre-allocate a large space now
> for future extensions?

cpu_features will grow a bit.  But I don't know by how much.

-- 
H.J.