Okay, so I'm trying to figure out whether this readlink(2) bug in qemu-mipsel is a user-mode or system-mode issue. Let's break it down. The problem occurs when using the readlink function on /proc/self/exe under QEMU. The expected behavior is that readlink returns the number of bytes written into the buffer, which shouldn't exceed the buffer size. But in this case, it's returning 15 instead of 1, even though the buffer is only 1 byte. I know that readlink typically resolves a symbolic link and writes the result into the provided buffer up to the given size. If the resolved path is longer than the buffer, it truncates but still returns the actual length. But according to POSIX, when the buffer isn't big enough, it should return the length of the string without writing beyond the buffer. So why does this happen only in QEMU? Maybe the emulation layer is handling the system calls differently. Since /proc files are handled by the kernel, perhaps QEMU's system-mode emulation isn't correctly implementing the readlink function for these special files. Also, the user mentioned that regular files in /home work fine. That suggests it's specific to /proc, which is a pseudo-filesystem managed by the kernel. So maybe the issue lies in how QEMU emulates the procfs or handles system calls related to it. In this case, since the bug relates to handling a special filesystem and system call behavior, I think it falls under system-mode issues because it involves kernel-level operations and device emulation. system