blob: 805de874eb4f4a181f663c107798d915ff0a3670 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Alright, I'm trying to classify this bug report as either user-mode or system-mode related. The problem involves a segmentation fault when using QEMU in armeb mode (which is big-endian). The issue seems to be with the VDSO method for __clock_gettime64().
The user provided details about rebuilding glibc with VDSO disabled, which fixed the problem. They also included a stack trace showing that the crash occurs in clock_gettime.c at line 42, where it's making an internal vsyscall to vdso_time64.
From my understanding, VDSO (Virtual Dynamic Shared Object) is part of user-mode because it's a shared object used by user-space applications. QEMU's system emulation would handle the kernel and hardware parts, but since this issue is about a specific library call crashing in user space, it might be related to how QEMU emulates certain syscalls or handles memory for big-endian systems.
The fact that the problem doesn't occur on qemu-arm (little endian) suggests it's an emulation issue specific to armeb. Maybe there's a bug in how QEMU handles the VDSO for big-endian targets, leading to incorrect addressing or alignment when accessing memory during the vdso_time64 call.
Since the crash is happening within user-space code (glibc), and not at the kernel level, this seems more like a problem with the user-mode emulation provided by QEMU. Therefore, it's likely a user-mode related issue.
</think>
user
|