Hey Eliot,
I missed that thread:)
It looks like Ken included some FFI test cases in his patch code ... what would
you need over and above that? An actual C library?
Dale
On Apr 3, 2011, at 7:38 PM, Eliot Miranda wrote:
Hi Dale,
this is a known issue spotted and fixed by Ken Treis. I've been tardy in
integrating the fix. I'll try and do that in the next couple of days. A test
case would help (Ken, Dale?).
If you want to try Ken's fix in advance then see
http://lists.gforge.inria.fr/pipermail/pharo-project/2011-March/044521.html
Apologies,
Eliot
On Sun, Apr 3, 2011 at 1:04 PM, Dale Henrichs
<[email protected]<mailto:[email protected]>> wrote:
On Apr 3, 2011, at 12:48 PM, Dale Henrichs wrote:
>
> On Apr 3, 2011, at 12:36 PM, Dale Henrichs wrote:
>
>> Norbert,
>>
>> Today I have found that I can get GemTools to work on the mac using Squeak
>> 4.2.4beta1U.
>>
>> Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a
>> Space is low error, because the size comes back as 1330942246849085449,
>> instead of a reasonable number).
>>
>> The image is identical and the gci library file is identical in both cases,
>> I've just switched the vm that I'm using.
>>
>> Squeak 5.7.4.1 gives an 'unsupported calling convention' with the first FFI
>> call into the library.
>>
>> Cog-VM.r2378 gives a 'Could not coerce arguments' error for the FFI call
>> that returns the unreasonable number in 4.2.5beta1U...the argument to the
>> function is a SmallInteger (343552513) ... at least this error gives me hope
>> that I can figure out what's wrong with this call sooner or later ...
>>
>> Anyway, the upshot is that Squeak 4.2.4beta1U is the best bet at the moment
>> on the Mac for running GemTools ...
>>
>> Oh, the image was a PharoCore-1.1.1...Finding _a_ Mac vm, that works gives
>> me an incentive to try getting GemTools running on PharoCore.1.2...
>>
>> If any of the vm or FFI guys have some insight to these problems I'd
>> appreciate some pointers to what may be going on...
>
> Here's the FFI call:
>
> apiGciFetchObjImpl: anOopType
>
> <apicall: ulong 'GciFetchObjImpl' (OopType64) >
> ^self externalCallFailed
>
> and OopType64 is a subclass of ExternalStructure with the following fields
> declaration:
>
> fields
> "
> (OopType64 defineFields)
> "
>
> ^#(asOop 'ulonglong').
>
> and the function declaration from the header file:
>
> int GciFetchObjImpl(OopType theObject);
I thought it might be suspicious that a SmallInteger was being passed in when
the argument type should have been OopType, so in the Cog vm, I traced the
source of the argument back to the _result_ another FFI call:
<apicall: OopType64 'GciNbPerform' (OopType64 char* ulong long) >
The result is declared as OopType64 so it looks like the result was not
converted to the correct type on return...which ends up with the incorrect
argument coming in ..
When the Squeak 4.2.5beta1U runs through the same sequence of calls, the
result of GciNbPerform gets correctly converted to OopType64, so that seems to
be the ulitmate source of the error ...
Not sure whether this is a VM issue or an FFI issue, in either case I assume
that the bug exists in some C code floating around somewhere..
Dale
