glibc 2.12 support

[erik.joelsson at oracle.com]

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
>