Fixes an existing bug in dup3 handling on AArch64. As SYS_dup2 is not available on AArch64, SYS_dup3 was not being included in the switch in pre-syscall handling due to a misplaced conditional compile statement. Note that on AArch64 dup2 automatically uses dup3 internally, so the bug affected also the dup2 calls in the client.file_io test.
Fixes close_range handling on AArch64 by updating the syscall defines from a newer header file that does define __NR_close_range. Defines the SYS_close_range constant for AArch64.
Enables the client.file_io test on AArchXX. Replaces the inline asm code to unmask divide-by-zero exceptions, with a glibc wrapper. Also adds a test for dup3. The clone_range part of this test is enabled on AArchXX but hasn't been run yet, because our CI machine does not have kernel >= 5.9.
Also, on AArch64, unmasking of float-point exceptions in the setup of the client.file_io test may be ignored as trapping exceptions is optional. https://code.woboq.org/userspace/glibc/sysdeps/aarch64/fpu/feenablxcpt.c.html#37
Issue: #5131 (closed)
Activity
requested review from @derekbruening
270 308 */ 271 309 #ifdef WINDOWS 272 310 _control87(_MCW_EM & (~_EM_ZERODIVIDE), _MCW_EM); 311 #elif defined(LINUX) 312 if (feenableexcept(FE_DIVBYZERO) == -1) { 313 # ifdef AARCH64 314 /* This call may return EPERM on AArch64. 315 * https://code.woboq.org/userspace/glibc/sysdeps/aarch64/fpu/feenablxcpt.c.html#37 I see the same on https://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.lib_ref/topic/f/feenableexcept.html. Maybe worth adding Assad to understand this limitation better?
Also on https://code.woboq.org/userspace/glibc/sysdeps/aarch64/fpu/feenablxcpt.c.html#37 as mentioned in the PR's description.
So if the AArch64 hardware doesn't support floating-point traps, then this will return EPERM, and we do not fail the test. But we don't then have a test on hardware that does have traps; we could then have something untested and not realize it. Not sure failing the test is good either. It's similar to rseq or close_range or other things: we manually make sure our test machines have the feature, and we have the tests gracefully skip that if not present.
@AssadHashmi Is this something that can be solved by updating the kernel of the Jenkins machine? The first link says it's a limitation of the hardware (unmasking of floating-point exceptions being ignored), which makes me think updating the kernel might not help.
On a related note, there are some syscalls that aren't supported by the current kernel there, notably
close_range
. Not sure if it's easy to update the kernel on that machine. It is 5.4 I think, which is ~1.5 years old.
- Last updated by Abhinav Anil Sharma
- Last updated by Abhinav Anil Sharma