Re: NSInvocation return value location

[Sebastian Reitenbach]

David Chisnall <theraven@sucs.org> wrote: 
> On 1 Dec 2008, at 16:12, Richard Frith-Macdonald wrote:
> 
> > On 1 Dec 2008, at 15:54, David Chisnall wrote:
> >
> >> I've looked at GSFFCallInvocation and I can't work out why changing  
> >> the value of _retval does not alter where it stores the return  
> >> value.  av_start_ptr appears to be called with _retval as the  
> >> argument, but the result is written both to the location specified  
> >> there and on the original stack location.
> >>
> >> Any hints?
> >
> > A vague guess (I haven't looked at that code for a while, and didn't  
> > write it) ...  perhaps our code is passing the stack address to the  
> > called method, and then on return from that method is copying the  
> > data from the stack to the NSInvocation.
> 
> I don't think this is the case, since GSFFIInvocation does not exhibit  
> this behaviour, meaning it must be due to something in the invocation  
> itself, rather than in the caller.
> 
> > If you could get it fixed, that would be good, though I'm wondering  
> > if we shouldn't deprecate ffcall in favour of ffi anyway, as using  
> > ffcall seems to mess up the stack unwinding done by native objc  
> > exceptions (meaning that an exception raised in a method called via  
> > an invocation will cause the program to crash) and the stack trace  
> > reporting done by exceptions (whether native or the more normal  
> > setjmp/longjmp based implementation).
> 
> Having only one implementation would be simpler, certainly.  Ffcall  
> seems to be built by default (it's what I had without specifying which  
> to use).  Are there some platforms where only ffcall works?  If not,  
> I'd be in favour of deprecating it...
The OpenBSD ports are based on ffcall, as there is no official port of 
libffi. Two or three weeks ago, I created a port for libffi for me, to play 
around with it, but its not in the official tree yet.
However, I had the problem, with both installed, ffcall and libffi, in the 
same location, below /usr/local/lib and /usr/local/include, and also with 
the parameter --enable-libffi, it linked against ffcall when it was found.
I had to uninstall ffcall to be able to link against libffi.

Sebastian