On Wed, Mar 16, 2011 at 4:25 PM, Ken Treis <ken@miriamtech.com> 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.