blob: 61358fb6871fb24aaf4de831158474a91dacbc2c (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I have this bug report about QEMU and RISC-V. The issue is that when using qemu-user to run a program on RISC-V 64, the signal frame gets misaligned by 4 bytes instead of 16 bytes, which causes problems like UBSan pointer misalignment errors.
Let me break down what's happening here. The user provided a C program that sets up a signal handler using sigaction with SA_SIGINFO flag, so it expects both info and context pointers in the handler. Then they deliberately misalign the stack by subtracting 4 from sp, which might be part of their test setup.
When they run this under qemu-riscv64 and send SIGINT, the output shows that the signal frame isn't aligned properly. The addresses for info and context are at offsets that don't seem to be multiples of 16, which is what RISC-V typically requires for proper stack alignment.
Looking deeper, the user mentioned that QEMU's source code points to this issue in the signal handling part. They reference a specific line where the constant might be set incorrectly—changing it from whatever it was to 15 would fix the alignment because 16-byte alignment requires shifting by log2(16)=4 bits, so mask with 0xf (which is 15) for proper alignment.
Now, classifying this bug: It's related to how QEMU handles signals on RISC-V. The problem arises during runtime when the signal is processed. So it's not about an instruction being faulty or a syscall issue but rather something that happens while executing code—specifically in handling signals and their frames.
Therefore, this falls under 'runtime' errors because it occurs during the execution of the program when the signal handler is invoked.
</think>
runtime
|