Alright, so I need to classify this bug report as either user-mode or system-mode related in QEMU. Let's break down the problem. The issue is about user space emulation where certain syscalls like openat() are causing problems with path translation involving a sysroot. The user provided steps to reproduce involve compiling a test program and running it under qemu-arm, which I believe is the user-space emulator for ARM. From what I know, QEMU has two main modes: system-mode (which emulates an entire OS, including hardware devices) and user-mode (which runs applications directly on the host kernel without full OS emulation). In user-mode, QEMU translates syscalls from one architecture to another. The problem here seems to be with how paths are being translated when using openat(). The strace shows that opening /tmp is actually opening SYSROOT/tmp. Then, when using openat, it fails because the fd points into the sysroot instead of the expected location. Since this involves handling file descriptors and path translations in user-space processes, without mentioning any hardware or low-level device interactions, it's likely a user-mode issue. System-mode would involve more about how the OS is running on virtualized hardware, not just application-level syscalls. So, I think this bug falls under user-mode. user