blob: a91ed61d83876541287426e5422c04ca353d72ad (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I need to classify this QEMU bug report as either user-mode or system-mode. Let me go through the information provided.
The issue is about Sparc32plus having x86 code generation errors on 64-bit hosts. The problem occurs in load and store functions when compiling under certain conditions, leading to access violations seen during debugging with GDB.
Looking at the code snippets, the bug seems to involve how instructions are translated into x86 assembly. Specifically, there's an issue with address masking and 32-bit operations within a 64-bit environment. The generated code includes problematic lines like 'mov %ebx,%ebx' which might be causing issues.
The user mentions that this affects Sparc32plus when running on a 64-bit host, leading to access violations not present in powerpc mode. They tried disabling gen_address_mask() but it didn't fix the issue and made the system unusable.
Now, considering whether this is user-mode or system-mode: User-mode issues relate to guest programs executing within QEMU without involving high-level system operations. System-mode involves emulating devices, higher privileges, or OS interactions.
This bug seems to be in how the CPU instructions are translated, which affects the execution of guest code. It doesn't directly involve device emulation or OS-level tasks but rather the translation of Sparc instructions into x86. Therefore, it's more about user-mode code generation and execution within QEMU.
</think>
The issue pertains to how user-space programs are emulated in QEMU, specifically with incorrect code generation for load and store operations on a 64-bit host.
user
|