vcomp: single-threaded implementation of _vcomp_fork (try 6)
dank at kegel.com
Wed Oct 24 07:31:08 CDT 2012
On Wed, Oct 24, 2012 at 3:26 AM, <Joerg-Cyril.Hoehle at t-systems.com> wrote:
> Alexandre Julliard wrote:
>> +void WINAPIV _vcomp_fork(BOOL ifval, int nargs, void *wrapper, ...)
>> + __ms_va_list valist;
>>it's ugly to use varargs only as a hack to get a pointer to the first
> Would taking the address of &wrapper (as in asm("...","r=&wrapper") or
> any C code like "void* stack = &wrapper") suffice to tell the x64
> compiler to save register parameters into their allocated stack
> My belief was that this is specifically the magic performed when the
> compiler sees a [__ms_]va_list.
> You seem to imply that va_list is superfluous and that
> taking the address of any parameter (not necessarily &wrapper
> but &ifval or &nargs too) would achieve the same effect: all 4 registers
> rcx, rdx, r8 and r9 get saved to the stack such that the & abstraction
> works even when the user performs pointer arithmetic.
I don't think he's saying that.
It suffices that taking the address of the fourth parameter saves it
to the stack.
We are lucky in this case that there are already three
non-varargs parameter, so after taking the address of the fourth
parameter, all the varargs params are in memory.
It all just happens to work (at least on ia32 and x64).
> In such a case he would use &wrapper, bypass va_list and correct the
> stack-relative offsets in the x86 and x64 assembly code by one pointer unit.
I don't think it's that complicated.
Here's a draft that does what Alexandre suggests.
It seems fine to me and to Daniel Lehman, and I was about to
submit it when I got Jörg's reply.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 17358 bytes
Desc: not available
More information about the wine-devel