blob: 3795c00303bc37fa25cac607237d41caa4e4a02d (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
<think>
Alright, let's try to figure out whether this bug is user-mode or system-mode related.
So the issue is that when running `strip` on a target file in a FreeBSD aarch64 environment within QEMU, it results in a segmentation fault. The backtrace shows that the problem occurs in `libc.so.7` at the `memcpy` function, which suggests that perhaps there's an issue with memory handling.
Looking deeper into the stack trace:
- The first frame is `libc.so.7`'s `memcpy`, specifically at address 0x40312f40.
- The second frame is in `libelf.so.2` where it's calling `_libelf_cvt_HALF_tom`.
- Then it goes into `strip` functions like `copy_data` and `create_elf`.
Since the issue arises within user-space programs (`strip` and others), it's more likely a problem with how QEMU is emulating the CPU or handling memory in user mode. The segmentation fault occurs when executing code that should be running in user space, not during system calls.
Considering that QEMU's TCG (Tiny Code Generator) is being used for acceleration, maybe there's an issue in how it handles certain instructions or memory operations on the aarch64 architecture. This could affect user-mode applications but wouldn't directly involve kernel-level components unless the emulation layer is flawed.
Additionally, the fact that physical boxes don't exhibit this problem suggests that it's specific to QEMU's environment rather than the host or guest OS setup. Therefore, the issue is probably related to how QEMU emulates aarch64 in user mode.
</think>
user
|