1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I'm trying to figure out how to classify this bug report about QEMU and ARM semihosting. The user provided some details that might help me understand what's going on.
First, they mentioned that when using the HEAPINFO semihosting call in QEMU, there's an issue where data is written to the wrong address. According to the ARM documentation, the parameter register should point to a pointer of a four-field data block. But it looks like QEMU is treating this register as pointing directly to the data block instead.
The user provided a link to their code example, which uses newlib in semihosting mode and calls HEAPINFO during the crt0 routine. When they run this in QEMU, the program crashes either due to an invalid write or memory corruption, depending on how the program is structured.
They also referenced a discussion with the newlib community where this issue was brought up. From what I gather, the problem arises because of how QEMU handles the parameter for the semihosting call. It seems like it's not interpreting the pointer correctly.
Now, looking at the possible categories: instruction, syscall, or runtime. The bug isn't about a faulty instruction itself but rather about how parameters are handled during a system call (HEAPINFO is a semihosting SVC call). However, the issue doesn't seem to be directly related to a system call per se but more about the runtime environment—specifically, memory management and how pointers are used.
The problem occurs at runtime when QEMU processes the parameter incorrectly, leading to invalid writes or memory corruption. This suggests that it's a runtime error because it happens while the program is executing, not during compilation or instruction execution itself.
So, putting this together, I think the category should be "runtime" since the issue arises from how the runtime environment (QEMU) handles the data structures passed to semihosting calls.
</think>
runtime
|