blob: eb39b42311f209db3743b0b78ed1161a9c92b2d7 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Alright, I'm trying to figure out how to classify this bug report about QEMU hanging when running MIPS and MIPS64 programs. The user provided details about compiling a program that uses weak symbols, leading to a crash but instead causes QEMU to hang.
First, looking at the issue: the program is statically linked and uses a weak pointer which should evaluate to NULL. On other systems, this would cause a crash, but with QEMU in user mode for MIPS and MIPS64, it hangs. The GDB output shows that QEMU is stuck inside `gen_intermediate_code`, specifically at `__lll_lock_wait` due to a mutex lock.
I need to categorize this bug into one of three categories: instruction, syscall, or runtime.
- **Instruction**: This would involve an incorrect handling of CPU instructions.
- **Syscall**: Issues related to system calls not being handled properly by QEMU's user mode.
- **Runtime**: Other runtime errors that don't fall into the first two categories.
The problem seems to stem from how QEMU handles threading or locks in its translation process. The mutex lock is part of the thread handling, and since it's causing a deadlock, this points more towards runtime issues rather than instruction execution or syscalls.
So, this bug is likely a **runtime** error because it's related to how threads are managed during the execution, leading to a hang rather than an issue with instructions or system calls.
</think>
runtime
|