Re: glibc 2.27: less than two weeks till release

[Romain Naour <romain dot naour at gmail dot com>]

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