1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Okay, so I need to classify this bug report into one of the given categories. The possible categories are mistranslation, assembly, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
The bug report is about readlink(2) returning an incorrect size for /proc/self/exe when using QEMU. From the steps to reproduce, it looks like they're compiling a test program with a MIPS cross-compiler and running it under QEMU. The issue is that readlink returns 15 instead of 1 as expected.
Hmm, readlink is a system call that reads the target of a symlink. In this case, when run natively on Linux, it works correctly (returns 1), but in QEMU, it's returning 15, which seems too large. The user points out that this only happens for links within /proc, not regular files.
So what part of QEMU could be causing this? I know that QEMU emulates system calls, so maybe there's a problem in how readlink is being translated or handled in the emulated environment.
Looking at the categories: 'files' relates to file operations, which includes system calls like readlink. The issue here isn't about translation between source and target architectures but rather about a system call behavior in the emulated environment.
Alternatively, could it be related to permissions? No, because the problem is with the size returned, not access rights. It's more about how the function behaves, which points towards 'files' as the category.
Other possibilities like device or network don't seem relevant here since readlink isn't directly interacting with devices or networking. The bug is specific to file system operations within QEMU.
</think>
The issue relates to a system call (readlink) misbehavior in the emulated environment, specifically with file operations. Therefore, the category is:
files
|