Messages in this thread | | | From | Andrew Lutomirski <> | Date | Fri, 5 Aug 2011 17:00:44 -0400 | Subject | Re: New vsyscall emulation breaks JITs |
| |
On Fri, Aug 5, 2011 at 4:52 PM, Andi Kleen <andi@firstfloor.org> wrote: > On Fri, Aug 05, 2011 at 01:48:28PM -0700, H. Peter Anvin wrote: >> On 08/05/2011 01:45 PM, Andrew Lutomirski wrote: >> > >> > hpa: time is supported (as of 3.0) by the vdso, and very new glibc >> > uses the vdso version. We could add a native time implementation back >> > to the vsyscall page without too much pain as a short-term fix, but >> > that would be less than ideal. >> > >> >> How new does glibc have to be? > > Mine from May 17 doesn't support it.
c738465a4c13370f58b797a82cdf1c67e1121867 from May 28.
> >> How much of a pain would it be to make the legacy vs emulated vsyscall >> page a config option? > > CONFIG_DONT_BREAK_MY_BINARIES? >
If gettimeofday could be a pure syscall fallback, then it wouldn't be so bad. With the vread_tsc changes, the vsyscall page can't directly call ->vread anymore, and making *that* conditional would be rather ugly.
> If anything runtime, but really for me it looks like the vsyscall > changes should be only in one of those limited compability paranoia > patchkits.
Switching it in runtime would be a giant mess because user code might be executing from the vsyscall page while we try to switch it. Switching at boot time might not be so bad. We'd just compile the emulation code in unconditionally but have a fallback page that we could map if needed.
I also filed this issue: https://code.google.com/p/dynamorio/issues/detail?id=530
--Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |