This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.27: less than two weeks till release
Hi Joseph,
Le 29/01/2018 à 17:28, Joseph Myers a écrit :
> On Sun, 28 Jan 2018, Romain Naour wrote:
>
>>> The microblaze/kernel-features.h needs to undefine
>>> __ASSUME_COPY_FILE_RANGE under such a condition, yes, much like it handles
>>> various other syscalls added later than on other architectures - but it
>>> would be appropriate to make a check for all glibc architectures to see if
>>> there are any others for which the default (>= 4.5) definition of
>>> __ASSUME_COPY_FILE_RANGE is wrong.
>>>
>>
>> For now, I only tested with kernel headers 4.9 on several architectures (arm,
>> aarch64, x86, x86-64, powerpc, powerpc64, nios2, sh, sparc).
>>
>> copy_file_range has been added for xtensa in 4.9, sh in 4.8, aarch64 in 4.7, so
>> the default (>= 4.5) definition of __ASSUME_COPY_FILE_RANGE is wrong for them.
>
> That aarch64 change looks like it was just for the compat syscall table
> (so possibly relevant for the arm port), not for the normal one?
I'm not sure it worth the effort to keep the support for kernel headers between
4.4 and 4.9 (i.e: kernel not maintained anymore). Buildroot has already removed
4.5 to 4.8 kernel headers selection.
>
> (glibc doesn't support xtensa; there is/was a port, but it's never been
> upstreamed.)
Right.
>
> It seems alpha added mlock2 and copy_file_range only in 4.13 (kernel
> commit a720830613eaa25eb5bc9b76705a88a36296709a - which has a load of
> other syscalls as well, but not ones that currently have __ASSUME_*
> macros). There may well be other such issues; a proper review is
> certainly needed. Things were correct (based on my review) as of glibc
> commit 6d08b0223aa3b3152ea7e9beb2b8f2a151b43109; it's __ASSUME_EXECVEAT,
> __ASSUME_MLOCK2 and __ASSUME_COPY_FILE_RANGE that need careful attention
> to when each architecture actually added the syscall to both asm/unistd.h
> and the syscall table.
>
I can't test with alpha architecture, but for other architectures supported by
Buildroot all syscall are correctly defined.
Best regards,
Romain