blob: 55cea53784888bc1a9cc0a2ac3bcf1eea22db1e7 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, let's see. The user is talking about QEMU user mode and issues with binfmt_misc configuration. They mentioned that when using chroot with qemu-user-static, some tests fail because the output includes the full path like /bin/tar instead of just tar. The problem seems to be related to how binfmt_misc passes arguments to QEMU.
They explained that the binfmt_misc config has flags including "P", which affects whether argv[0] is sent. When they modified the flags to include "P", binfmt_misc sends argv[0], but then chroot can't start bash because QEMU doesn't handle that extra argv[0]. They tried modifying QEMU's code to handle the new argv list, and found that the original command is in argv[2].
The user is asking if it's possible for binfmt_misc to pass an additional argument or environment variable to QEMU so that QEMU can know how to parse the arguments based on the binfmt_misc flags.
Now, to classify this bug. The options are instruction, syscall, or runtime.
Looking at the problem: it's not about a specific instruction being wrong. The issue is about how QEMU handles the arguments passed by binfmt_misc. When the flags change, the way arguments are passed changes, leading to QEMU not correctly interpreting the original command. This seems to be a runtime issue because it's about how the program behaves during execution, specifically argument parsing and handling. There's no mention of a specific syscall error here. The problem is in the runtime processing of the arguments, which QEMU isn't handling correctly when binfmt_misc's flags are set a certain way. So the category should be runtime.
</think>
runtime
|