In Ubuntu Lucid, libpthread contains calls to the x86-64 vsyscall page:

$ objdump -d /lib/libpthread.so.0 ... ae50: 48 c7 c0 00 00 60 ff mov $0xffffffffff600000,%rax ae57: ff d0 callq *%rax ... (This is a call to vgettimeofday.)

When I disassemble these functions in a sandboxed process using gdb, I can see that the SYSCALL instructions have been patched, but the indirect calls to the vsyscall page have not. There is code in library.cc for patching indirect calls, but it is only enabled for patching the vdso.

In practice, the vsyscall calls seem to be conditional on __have_futex_clock_realtime being false. libpthread won't call vgettimeofday on a kernel that supports FUTEX_CLOCK_REALTIME.

This issue might be behind the problem with Linux 3.1 (issue chromium:104084), but I need to investigate more.

This is a difficult problem to solve in general, because it's probably not practical to enable library.cc's indirect-call patching code for libpthread.so or libc.so. The kernel does not allow us to patch the vsyscall page (which is in the kernel range of address space), unlike the vdso. However, the vsyscall page is deprecated, so we probably don't need to handle the general case.

libc.so contains a couple of unconditional calls to the vsyscall page that we need to patch, for time() and sched_getcpu().

$ objdump -d /lib/libc.so.6 ... 0000000000099ed0 : 99ed0: 48 83 ec 08 sub $0x8,%rsp 99ed4: 48 c7 c0 00 04 60 ff mov $0xffffffffff600400,%rax 99edb: ff d0 callq *%rax 99edd: 48 83 c4 08 add $0x8,%rsp 99ee1: c3 retq
...

This definitely breaks on Linux 3.1, where vtime always executes a SYSCALL instruction.

I suggest we handle these two cases by making the patcher look for this instruction sequence: mov $0xffffffffff600x00,%rax callq *%rax

Fixed in r178.