Hello Florian,
We still build with glibc 2.12 in the sysroot at Oracle as we still
support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still
need it.
/Erik
On 2021-12-13 05:21, Florian Weimer wrote:
It seems that building against glibc 2.12 is still supported. Is this
something that is still needed?
I'm mostly concerned with this fallback code on x86-64:
// Unfortunately we have to bring all these macros here from vsyscall.h
// to be able to compile on old linuxes.
#define __NR_vgetcpu 2
#define VSYSCALL_START (-10UL << 20)
#define VSYSCALL_SIZE 1024
#define VSYSCALL_ADDR(vsyscall_nr)
(VSYSCALL_START+VSYSCALL_SIZE*(vsyscall_nr))
typedef long (*vgetcpu_t)(unsigned int *cpu, unsigned int *node, unsigned
long *tcache);
vgetcpu_t vgetcpu = (vgetcpu_t)VSYSCALL_ADDR(__NR_vgetcpu);
retval = vgetcpu(&cpu, NULL, NULL);
There is no way to check that the kernel actually supports vsyscall, and
on some kernels, this will crash because they have disabled vsyscall.
I would like to remove this or switch over to the system call (as
already used on i386). This is fallback code only, so performance does
not really matter: on newer glibc (starting with 2.14), sched_getcpu
will be found, and it will use vDSO or rseq as appropriate.
Thanks,
Florian
