Skip to content

VDSO on armeb seems broken

Host environment

qemu for this report is qemu-9.0.0 running qemu-armeb, glibc is cross-armeb-linux-gnueabihf/glibc-2.39-r4 (Gentoo Linux). The problem was also apparent on qemu-8.2.1. Host is probably irrelevant but it's Gentoo Linux unstable on a gen 1 Threadripper and kernel 6.7.9.

Emulated/Virtualized environment

armeb-linux-gnueabihf

Description of problem

I'm seeing the VDSO method for __clock_gettime64() crashing under qemu-armeb (stack trace under Additional information, below).

I rebuilt glibc with VDSO globally kludged off, and all was well.

Steps to reproduce

#include <time.h>
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv) {
  time_t ts;
  printf("%ld\n", time(&ts));
  exit(0);
}

Results, first with VDSO active via a system snapshot, second with the patched glibc:

$ armeb-linux-gnueabihf-gcc -o /tmp/time /tmp/time.c
$ qemu-armeb -L /.mirrorsnaps/.rootsnap.prev/usr/armeb-linux-gnueabihf /tmp/time
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
$ qemu-armeb -L /usr/armeb-linux-gnueabihf /tmp/time
1715123280

Additional information

Program received signal SIGSEGV, Segmentation fault.
0x4082b462 in ?? ()
(gdb) bt
#0  0x4082b462 in ?? ()
#1  0x40bf64a4 in __GI___clock_gettime64 (clock_id=clock_id@entry=5, tp=tp@entry=0x407fe9c0)
    at ../sysdeps/unix/sysv/linux/clock_gettime.c:42
#2  0x40be9f58 in __GI___time64 (timer=0x0) at ../sysdeps/unix/sysv/linux/time.c:60
#3  __time (timer=0x407fea04) at ../sysdeps/unix/sysv/linux/time.c:73

clock_gettime.c:42 is

      r = INTERNAL_VSYSCALL_CALL (vdso_time64, 2, clock_id, tp);

Interestingly, the problem doesn't occur on qemu-arm (little endian), all else equal.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information