blob: 8c34d2fb3aa0b18e1e00588498448d3fa199be9d (
plain) (
blame)
1
2
3
4
5
6
7
8
9
|
<think>
Okay, let's see. The user is describing an issue with execveat when using a file descriptor and an empty filename across different architectures. The problem occurs when running on non-x86_64 architectures like arm64 or riscv64, returning ENOENT. They mention that when using QEMU with binfmt_misc, the x86_64 and x86 work, but others fail. The test code works when using /proc/self/fd instead of the AT_EMPTY_PATH flag.
Hmm, execveat is a system call. The problem seems to be that when using AT_EMPTY_PATH with a file descriptor, some architectures under QEMU return ENOENT. Since the user says it works natively for those architectures, but not under QEMU, this might be a QEMU-specific issue. The error is related to how QEMU handles the execveat syscall with the AT_EMPTY_PATH flag for certain architectures. The fact that disabling binfmt_misc changes the error to ENOEXEC suggests that QEMU's handling of the syscall is involved here.
The categories are instruction, syscall, or runtime. Since the problem is with the syscall (execveat) and how QEMU processes it for different architectures, this would fall under the syscall category. The issue isn't about a wrong instruction but how the syscall is handled during execution, especially in the user-mode emulation of QEMU. So the correct classification is syscall.
</think>
syscall
|