syscall 437 (on amd64), openat2, is not implemented by Valgrind.
Do you have a small testcase to reproduce this?
Created attachment 136343 [details] Program which demonstrates the use of the openat2 syscall Sure thing. Here's a test program.
Created attachment 143181 [details] diff for opnenat2 Here is the start of an implementation. Mostly it's just a copy/paste of sys_openat, with the args changed to use struct open_how*, and also to do more thorouhg checking of the args. I'm not sure if the values of VKI_O_DIRECTORY / VKI___O_TMPFILE / VKI_O_TMPFILE are generic across Linux hardware platforms. If they are then they need to be moved to include/vki/vki-linux.h. If not they need to be moved to the platform versions of vki-linux.h
Created attachment 143183 [details] patch for openat2 This time - make sure masks are extended to unsigned long long - use resolved field rather than mistakenly mode
I had a little difficulty compiling the example code, ended up copying/pasting a few ofd the octal flags from /usr/include/asm-generic/fcntl.h directly into the file. I based the mode/flags and resolve checks on this comment in openat.h * Arguments for how openat2(2) should open the target path. If only @flags and * @mode are non-zero, then openat2(2) operates very similarly to openat(2). * * However, unlike openat(2), unknown or invalid bits in @flags result in * -EINVAL rather than being silently ignored. @mode must be zero unless one of * {O_CREAT, O_TMPFILE} are set.
Created attachment 143184 [details] patch for openat2 Third time lucky with the flag checks.
Hmm. I should perhaps land this. Need some tests (scalar at least).
Should be fixed with this commit commit 2c93baf53a652fd503c0c21bccb7e85363f43e58 (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Fri Jan 6 21:27:01 2023 +0100 Bug 433873 - openat2 syscall unimplemented on Linux This syscall is not exposed via glibc, so there is only an addition to the scalar test.