Compatibility issues around <sys/platform/x86.h>
Adhemerval Zanella
adhemerval.zanella@linaro.org
Tue Dec 22 12:43:27 GMT 2020
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?
More information about the Libc-alpha
mailing list