On 4. Apr 2019, at 08:36, Holger Freyther <holger@freyther.de> wrote:
And I have a stand-a-lone testcase for Pharo as well: https://github.com/zecke/pharo/commit/390f81241a7dfee546784453fa426bc1c218b3... Any hint of how I can test (simulate?) and generate changes to ThreadedX64SysVFFIPlugin from Pharo (or how you normally do it in Squeak). cheers holger
In addition to my mail from yesterday to vm-dev I want to share the following example to illustrate the problem. I have taken StructA and StructNested from the FFIExternalStructureReferenceHandle class comment and put it into Unclassified.st that is attached to this mail. I am also making a call to LibC's getpid and try to push StructNested to the stack. The ffiCall is failing before getpid is called (Bad argument to external function).
The reproducer is:
StructA new theNest anyCall.
StructA has a ByteArray handle of the full struct. theNest returns an instance of StructNested with a FFIExternalStructureReferenceHandle. This makes sense as well. It can't be a copy of the ByteArray (or else updates would be invisible to the outer struct) and it can't be an ExternalAddress as StructA's handle might move in the Smalltalk heap.
I am not entirely sure how this is should work but what do you think of:
1st) Extending ExternalStructure class comment to list FFIExternalStructureReferenceHandle as possible handle type? I think we would only describe the reality.
2nd) ThreadedFFIPlugin>>#ffiPushStructureContentsOf: should be aware of FFIExternalStructureReferenceHandle and know how to reach the handle. Or should there be something in the image converting this to a ByteArray when being pushed as value in a ffiCall?
comments/ideas?
<Unclassified.st>