[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSInvocation return value location
From: |
Sebastian Reitenbach |
Subject: |
Re: NSInvocation return value location |
Date: |
Mon, 01 Dec 2008 21:57:21 +0100 |
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
>