blob: a00d97bc99b8d77704a7923a8251662f66798285 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, I need to classify this bug report as either user-mode or system-mode related. Let me read through the problem description carefully.
The issue is about strace not showing execve syscalls when running a mipsel application using QEMU 6.2.0. The user provided steps to reproduce and some logs. They mentioned that older versions, like QEMU 4.2.1, did show the execve calls.
In the problem description, they built QEMU with user mode support (mipsel-linux-user) and used it to run a test application. When they tried to strace it, the execve calls from system and popen weren't showing up. They think this might be because execve doesn't return on success, but older versions handled it.
Strace is a user-mode tracing tool that intercepts and records system calls made by processes. If QEMU isn't allowing strace to capture these calls properly, it's likely an issue with how user-mode emulation handles syscalls or debugging.
Looking at the target list in the configure command (--target-list=mipsel-linux-user), this is definitely about user-mode execution since they're emulating a mipsel Linux environment without a full OS. The fact that strace isn't capturing execve suggests something's wrong with how QEMU handles these syscalls in user mode, maybe a regression introduced between versions 4.2.1 and 6.2.0.
System-mode issues would involve higher-level privileges, devices, or the host OS interacting differently, but this seems purely about executing a userspace application and tracing its system calls. So it's more about how QEMU's user-mode emulation interacts with strace.
</think>
user
|