blob: f192fca1f4617edf9e013ff4fa8f7345d416e203 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, let's see. The user is describing a bug where readdir() returns NULL with errno EOVERFLOW when using 32-bit user-static QEMU on a 64-bit host. They provided a code example and steps to reproduce. The root cause seems to be in glibc's handling of getdents64, checking if inode numbers and offsets fit into 32-bit ranges. The problem arises because QEMU is passing through 64-bit inode numbers from the host kernel, which are too large for the 32-bit application's expectations.
The user mentions that on real hardware with a 32-bit kernel, the inode numbers are 32-bit, so it works. But in QEMU's case, since it's emulating a 32-bit user space on a 64-bit host, the syscall (getdents64) returns 64-bit values. The glibc code checks for 32-bit compatibility and triggers EOVERFLOW when the values are out of range.
The question is to classify this bug into one of the categories: instruction, syscall, or runtime.
The issue is related to how syscalls are handled. Specifically, the getdents64 syscall is returning data that the 32-bit application can't handle because the values are too big. The problem stems from the syscall interface between the 32-bit user space and the 64-bit kernel. QEMU is supposed to translate syscalls appropriately, but here it's passing through the 64-bit inode numbers directly, which leads to the overflow.
Since the core of the problem is the syscall (getdents64) returning values that are incompatible with the 32-bit application, the correct category would be "syscall". The error arises from how the syscall's data is handled between the host and the emulated environment.
</think>
syscall
|