One more addition is that the exact definition of OopType is this: typedef uint64_t OopType;
On Thu, Mar 31, 2016 at 10:51 AM, Mariano Martinez Peck < [email protected]> wrote: > OK...I have some more info...please read the end if you have little time. > > I have the same error for even a simpler function: > > GCI_ALIGN_STACK EXTERN_GCI_DEC(OopType) > GciFetchClass(OopType theObject); > > which I call this way: > > apiGciFetchClass: theObject > > ^ self ffiCall: #( GsGciOopType GciFetchClass(GsGciOopType theObject) ) > > The arguments I receive at runtime (theObject) prints to something > like "GsOopType(200635137)" so...at least it looks like a valid object > with a valid handle. > > I suspect there might be something wrong with the GsGciOopType (subclass > of FFIExternalStructure). > *In the original C specification it says that OopType should be an > unsigned 64-bit integer.* > > *The way this was mapped BEFORE (with old FFI) was like this:* > > *fields* > "self compileFields" > "self byteSize" > * ^ #(nil 'ulonglong')* > > *BTW... i don't understand that nil there. * > > And...with the OLD FFI, GsGciOopType (originally subclass of > ExternalStructure) was managed like an integer directly. For example, above > GciFetchClass would directly answer the integer (the ulonglong field). > > With the new approach I am doing: > > fieldsDesc > > ^ #( > ulonglong oop; > ) > > But now... for example above GciFetchClass would answer an instance of > GsGciOopType to which I must send #asInteger to get the integer value. > > > So...I suspect the same problem might be in the marshaling of the > GsGciOopType instances I pass as argument. Maybe previously arrived already > as integer to C while now it's different. > > Any pointer is appreciated. > > > > > > On Thu, Mar 31, 2016 at 10:27 AM, Mariano Martinez Peck < > [email protected]> wrote: > >> >> >> On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano <[email protected]> >> wrote: >> >>> how does your function call looks like? >>> >>> >> >> The function call is: >> >> ^ self ffiCall: #( GsGciOopType GciExecuteStrFromContextDbg_(String >> source, int64 sourceSize, GsGciOopType sourceClassOopType, GsGciOopType >> contextObjectOopType, GsGciOopType symbolListOopType, int flags, ushort >> environmentId) ) >> >> >> And the C function SHOULD BE (I say SHOULD because I don't have access to >> the C source nor header): >> >> EXTERN_GCI_DEC(OopType) >> GciExecuteStrFromContextDbg_( >> const char source[], int64 sourceSize, OopType sourceClass, >> OopType contextObject, OopType symbolList, >> int flags, ushort environmentId ); >> >> >> I am not sure which is the error because other times I did get an error >> that is was clear that it couldn't marshal the arguments. But that "bad >> arguments" doesn't tell me much :( >> >> >> >> >> On 31 Mar 2016, at 04:55, Mariano Martinez Peck <[email protected]> >>> wrote: >>> >>> Hi guys, >>> >>> Could someone help me understand what could be the exact reason of >>> a 'Bad argument for external function' in an FFI call? Of course, I double >>> checked all the arguments definitions in the #ffiCall: and the real objects >>> I receive as arguments at the moment of the callout. And they all seem >>> correct. >>> >>> And even better...how can I get more info about it? >>> >>> Thanks in advance, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com
