Re: glibc 2.27: less than two weeks till release

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

Hi Joseph,

Le 24/01/2018 à 23:02, Joseph Myers a écrit :
> On Wed, 24 Jan 2018, Romain Naour wrote:
> 
>>> It looks like copy_file_range was only added for microblaze in 4.10 
>>> (commit 7181e5590e5ba898804aef3ee6be7f27606e6f8b).  Which means the 
>>> definition of __ASSUME_COPY_FILE_RANGE is incorrect for microblaze - needs 
>>> an override in microblaze/kernel-features.h - and should be checked more 
>>> generally for all glibc architectures to determine the kernel versions in 
>>> which they had both the syscall table entry and the asm/unistd.h 
>>> definition.
>>>
>> So, __ASSUME_COPY_FILE_RANGE needs to be undefined for toolchain built with
>> kernel-headers < 4.10, right ?
> 
> 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.

Best regards,
Romain