On Wed, Mar 16, 2011 at 4:25 PM, Ken Treis <[email protected]> wrote:

> On Mar 15, 2011, at 3:36 PM, Eliot Miranda wrote:
>
> > I expect that if the standard FFI plugin answers an instance of OopType64
> then you've found a bug in the ReentrantFFIPlugin.  If you're brave you'll
> have a look at both plugins and try and verify that that's the case.  But I
> have to say that the FFI plugins are not simple.
>
> Brave, yes. Smart, no. Here's what it looks like to my untrained eye:
>
> 1. When the ExternalFunction is compiled, the return argType is not flagged
> as a structure. So the primitives, old and new, see this as a regular
> non-struct callout, but with return class = OopType64. So far, so good.
>
> 2. The old plugin had this one-slot "wrapping" capability at the bottom of
> #ffiCreateReturn: (which is called only for non-pointer, non-structure
> functions):
>
>        ffiRetClass := interpreterProxy popRemappableOop.
>        ffiRetClass == interpreterProxy nilObject ifTrue:[
>                "Just return oop"
>                ^interpreterProxy push: retOop].
>        "Otherwise create an instance of external structure and store the
> return oop"
>        interpreterProxy pushRemappableOop: retOop.
>        retOop := interpreterProxy instantiateClass: ffiRetClass
> indexableSize: 0.
>        oop := interpreterProxy popRemappableOop.
>        interpreterProxy storePointer: 0 ofObject: retOop withValue: oop.
>        ^interpreterProxy push: retOop.
>
> 3. There's some very similar code in FFIPlugin>>ffiCreateReturnStruct and
> ReentrantIA32FFIPlugin>>ffiReturnStruct:ofType:in: -- the main difference is
> a memcpy().
>
> Am I on the right track? If so, how would you like to see the code
> structured to get this feature restored? We could add a new
> wrap-if-necessary return method, or we could try to reuse
> #ffiReturnStruct:ofType:in: if we guarded the memcpy() with a flag check for
> FFIFlagStructure.
>

If you're happy producing a fix I'll take whatever works, a test case and
the I can always muck it up if I disapprove :)


>
> Or maybe there's a cleaner solution that's beyond my hazy view at the
> moment.
>

I think you're on the right track.  I probably misread when I wrote my first
cut.  Apologies.

best
Eliot


>
> --
> Ken Treis
> Miriam Technologies, Inc.
>
>

Reply via email to