Re: [Pyobjc-dev] [Pyobjc-checkins] [PyObjC-svn] r1856 - trunk/pyobjc/libffi-src/src/x86

[Ronald O. <ron...@ma...>]

On 26-jun-2006, at 19:53, Bob Ippolito wrote:

>
> On Jun 26, 2006, at 7:46 AM, Ronald Oussoren wrote:
>
>>
>> On 24-jun-2006, at 0:30, Bob Ippolito wrote:
>>
>>> On Jun 21, 2006, at 2:08 PM, ron...@re... wrote:
>>>
>>>> Author: ronaldoussoren
>>>> Date: Wed Jun 21 16:08:27 2006
>>>> New Revision: 1856
>>>>
>>>> Modified:
>>>>    trunk/pyobjc/libffi-src/src/x86/darwin.S
>>>>    trunk/pyobjc/libffi-src/src/x86/ffi_darwin.c
>>>>
>>>> Log:
>>>> Merge a patch that I found on the GCC list. The unittests now  
>>>> all pass, but
>>>> the OutlineEdit bug persists.
>>>
>>> This "assert" should GP(0) any time the stack is unaligned..  
>>> instead of only happening when the stack is unaligned and the  
>>> callee happens to use alignment sensitive instructions. It  
>>> doesn't seem to get triggered with any of the unit tests, though :(
>>
>> I'd expected that result. Adding the instruction at other  
>> locations where the stack should be properly aligned does make it  
>> possible to trigger the crash. I'm checking if this is actually a  
>> problem or just me misunderstanding the assembly code  
>> (ffi_call_SYSV seems to be the culprit). Time for a printout +  
>> written annotations.
>>
>> One possible point of trouble is struct returns. The assembly code  
>> that's generated by GCC for such functions ends with ("ret $4"),  
>> as does the assembly code that ffi_closure_SYSV is currently  
>> using. This seems to update the stackpointer during the return,  
>> which could well upset ffi_call_SYSV.
>
> CALL and RET update the stack pointer in that the jump target is  
> pushed or poppped off the stack respectively... I don't think they  
> can do anything else to the stack pointer.

But then what does "RET $4" do? This instruction is present at the  
end of functions that return a struct that isn't returned in  
registers. Given the assembly code that is generated for calls to  
such functions I'd expect that this updates the stack pointer beyond  
just popping of the instruction pointer, calls to such functions look  
like:

	call _somefunc
         subl $4, %esp

I'm tempted to say this is yet another bug in the compiler/ABI  
description, and a very odd one at that.


I'd expect that this won't really affect us because ffi_call_SYSV  
doesn't touch the stack pointer after the call to the actuall  
function until it returns, and the %esp is reinitialised from %ebp. I  
do however want to get this code 100% right to be absolutely sure  
that our problems aren't caused by some subtle interaction that I've  
overlooked.

BTW. I just noticed objc_msgSendSuper_stret (the implementation of  
[super ...] when the method returns a struct) might have a 'void'  
return-type in the C header file, but behaves as if is a function  
that returns a struct: it also returns with 'ret $4', or at least  
that is what the assembly code for [super adjustRect:rect] suggests,  
as does the assertion failure  that's currently crashing PyObjC's  
unittests. I'm going to adjust libffi_support.m: I'll have call  
ffi_call as if objc_msgSendSuper_stret returns a struct instead of  
using the declared C prototype. But that will have to wait until  
tomorrow, its now too late to think straight :-)

Ronald