[PATCH] elf: Do not read hwcaps from the vDSO in ld.so
Florian Weimer
fweimer@redhat.com
Tue May 26 13:47:25 GMT 2020
* Adhemerval Zanella via Libc-alpha:
> On 19/05/2020 14:06, Florian Weimer via Libc-alpha wrote:
>> This was only ever used for the "nosegneg" flag. This approach for
>> passing hardware capability information creates a subtle dependency
>> between the kernel and userspace, and ld.so.cache contents. It seems
>> inappropriate for toady, where people expect to be able to run
>> system images which very different kernel versions.
>
> I agree that such dependency is not suitable for current practices and
> environment where glibc is used. From digging the history of "nosegneg"
> flag it seemed a hack around some issue or limitation from XEN kernels.
> Do you have more information of what exactly nosegneg tried to prevent?
It used to select a glibc built with -mno-tls-direct-seg-refs. Not
doing complicated address calculations in segment-based accesses somehow
simplified things for Xen with paravirtualization. Our notes indicate
that this was caused by negative segment-relative references, so
-mno-tls-direct-seg-refs was likely too big a hammer.
In practice, this matters only in very few places in glibc where we
access TLS variables that are *not* in the TCB or the thread descriptor,
because those are at positive offsets.
An example would look like this:
Dump of assembler code for function __syscall_error:
0x0001f090 <+0>: endbr32
0x0001f094 <+4>: call 0x132b41 <__x86.get_pc_thunk.dx>
0x0001f099 <+9>: add $0x18cd8b,%edx
0x0001f09f <+15>: neg %eax
0x0001f0a1 <+17>: mov 0xdc(%edx),%edx
0x0001f0a7 <+23>: mov %eax,%gs:(%edx)
0x0001f0aa <+26>: mov $0xffffffff,%eax
0x0001f0af <+31>: ret
At the point of the %gs-relative load, %edx is negative because that's
where the TLS variables are.
With a little bit of care, the performance benefits would likely have
been achievable without a separate glibc build.
> LGTM, thanks.
>
> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Thanks.
Florian
More information about the Libc-alpha
mailing list