On Sun, Oct 18, 2009 at 5:09 AM, Jamie Lokier <ja...@shareable.org> wrote: [...] > > Please don't do that. Some code traces instructions through the > vsyscall/vdso page, and will be surprised if a syscall instruction > does not do what's expected based on the registers at that point. > > Also I don't know if anyone's done this, but I have played with the > idea of an optimising x86->x86 JIT translator (similar to valgrind or > qemu's TCG) which would include the vdso instruction sequence in it's > traces, just because it didn't treat that any differently from other > userspace code. Making the syscall instruction behave differently due > to EIP would break that sort of thing. > > There's no performance penalty in setting a few registers prior to > using the syscall instruction normally, so please do that.
My proposed patch intercepts vsyscall as soon as the PC is in the [VSYSCALL_START, VSYSCALL_END[ range, so all instructions in that range won't be translated. Doing it differently will cause problems due to the virtual address. > On x86_64, the vsyscall page has fixed address (see > linux/arch/x86/kernel/vsyscall_64.c), but the vdso usually has > variable address. > > On x86_32, the vdso has randomised address unless configurd to be a > fixed address. On older kernels it was a fixed address and some > binary programs assume they can call that. So QEMU can't do things properly and some binaries will fail, right? Laurent
