On 02/06/2010 03:50 PM, Laurent Desnogues wrote:
* target-i386 code should not have to know about
linux vsyscall
Given that we have to workaround 64-bit virtual
address limitations (cf. Richard mail and previous
discussions on the list), doing otherwise looks
difficult.
Actually, it should be easy for QEMU to handle this.
The application is given the address of the VDSO in the AT_SYSINFO and
AT_SYSINFO_EHDR entries of the auxvec (on the stack above argv and
environ). We can place this anywhere we like; the fact that the kernel
puts it in high memory is merely a convenience to the kernel.
There *is* a legacy vsyscall address in high memory, from before the
whole VDSO arrangement was worked out, but we could probably get away
with ignoring that. Certainly well behaved applications will be
honoring the VDSO when it is given.
* it is not possible to step into vsyscall code
using a debugger
How would you achieve that? Your guest OS
doesn't necessarily have the code mapped. I
think this has to be considered as other syscalls,
though slightly different.
If QEMU implements the VDSO, the page *will* be mapped, and the debugger
will Just Work.
I imagine that QEMU's VDSO would not have the complicated bits that the
kernel's version does, where it arranges to read the clock without going
into kernel space. I imagine QEMU would simply stuff a normal syscall
sequence in there, which would automatically be emulated in the normal way.
Have a stare at the linux/arch/x86/vdso directory to see how things work.
r~
