Re: NSInvocation return value location

[Sebastian Reitenbach]

Sebastian Reitenbach <sebastia@l00-bugdead-prods.de> wrote: 
> 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.
sorry, I meant it the other way around, libffi was always preferred, but I 
just recognized, that I overlooked the right parameter to configure all the 
time.. tzzz


> 
> Sebastian
> 
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>