|
From: Naveen K. <g_n...@ya...> - 2005-08-10 15:42:29
|
> > I think (unless I misunderstand) that this is a non-problem. > > Vex makes it easy to defer to the scheduler and simultaneously > > set the next-IP value to anything you like (any constant value > > known at translation-time). So for sysenter we"d merely need > > to tell vex what the where-next address is, and there"s already > > a struct to tell Vex that kind of stuff (eg, for ppc32 "dcbz" > > it needs to know the cache line size of the machine being simulated, > > and only Valgrind knows that). > > > > Shall I hack this up? > > Might be any idea. I believe that Solaris needs sysenter support > anyway if I remember correctly. > Done (1320/4337). Note, I realised later the above >scheme is > unnecessarily complicated. A sysenter now causes the >calling thread > to return to the scheduler with code >VEX_TRC_JMP_SYSENTER_X86. > It is the scheduler"s problem to fill in the thread"s >guest_EIP > with a valid restart address before letting it run >again. > >J According to this http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/ml/syscall_asm.s#65 sysenter operation is as follows The caller in userland has arranged that: - %eax contains the syscall number - %ecx contains the user %esp - %edx contains the return %eip - the user stack contains the args to the syscall So %edx contains the %eip to return to after sysenter is completed. Is that the same on Linux ? Naveen __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |