On 08/16/07 Joshua Isom wrote:
>> The optimization done by the parrot jit is invalid for the x86 C calling
>> convention: the area of memory containing the passed arguments
>> can be used as scratch space by the called function.
[...]
> Let's go with a Microsoft blog about it,
> <http://blogs.msdn.com/oldnewthing/archive/2004/01/08/48616.aspx>. With
> __stdcall, the callee cleans the stack. With __cdecl(used everywhere else,
> and in part of windows), the caller cleans the stack. If the ops are
> converted to __cdecl, it should help fix it(since the function shouldn't
> logically assume anything about how much stack space is available for
> clobbering). I'm having trouble finding anything about who owns the stack
> space. My personal view is that the caller owns that stack space, since it
> can also be used to store local variables, i.e. don't move around data
> that's in order for calling a function.
It doesn't matter if the call conv is cdecl or stdcall, you always end
up with arguments on the stack:
arg2
arg1
arg0
return ip
[possibly old ebp value]
The location where arg0, arg1 and arg2 are stored on the stack can and
will be overwritten by the called function, it doesn't matter if esp is
restored by the caller or by the callee. So, if someone wants to do the
following calls:
foo (1, 2, 3);
foo (1, 2, 3);
it can't emit (with cdecl):
push 3
push 2
push 1
call foo
call foo
add esp, 12
because the stack words where 1, 2 and 3 where stored may have been
overwritten by the first call to foo, resulting in garbage being passed
to the second call.
The called function knows that it can clobber the stack space where
arguments were passed to it (it is of course a compiler bug if it
changes data above the passed-in arguments).
lupus
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
