<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Holger,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 4, 2019 at 4:49 AM Holger Freyther <<a href="mailto:holger@freyther.de">holger@freyther.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br>
> On 4. Apr 2019, at 08:36, Holger Freyther <<a href="mailto:holger@freyther.de" target="_blank">holger@freyther.de</a>> wrote:<br>
<br>
<br>
And I have a stand-a-lone testcase for Pharo as well:<br>
<br>
<a href="https://github.com/zecke/pharo/commit/390f81241a7dfee546784453fa426bc1c218b39e" rel="noreferrer" target="_blank">https://github.com/zecke/pharo/commit/390f81241a7dfee546784453fa426bc1c218b39e</a><br>
<br>
<br>
Any hint of how I can test (simulate?) and generate changes to ThreadedX64SysVFFIPlugin from Pharo (or how you normally do it in Squeak).<br></blockquote><div><br></div><div>If I wanted to simulate I would:</div><div><br></div><div>- create a 64-bit VMMaker image using the scripts in the image directory (32bit works, but 64-bits is faster)</div><div>- prepare the Pharo image (32 or 64-bit) containing the FFI call so that either it is snapshotted so that it will perform the call immediately, or that a script can be used at start-up to initiate the call</div><div>- load this image in the simulator, e.g.</div><div><br></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>| cos |</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager PharoVM true).</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>cos systemAttributes at: 2 put: '<a href="http://segload.st">segload.st</a>'.</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>cos setBreakSelector: #primitiveCallout.</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>cos openAsMorph; run</div></div><div><br></div><div>- then, when I had fixed ThreadedFFIPlugin to function as I wanted I would either submit VMMaker.oscog to <a href="http://source.squeak.org/VMMakerInbox">http://source.squeak.org/VMMakerInbox</a> or commit directly to <a href="http://source.squeak.org/VMMaker">http://source.squeak.org/VMMaker</a></div><div><br></div><div>Now, the only problem here is that simulation can only proceed up until the point of actually trying to make the call. Currently the simulator isn't clever enough to actually simulate the call. But at least you'll be able to examine the state of the C stack, and the point of calling the foreign function in the simulator.</div><div><br></div><div>Holder, since much of this is probably very unfamiliar to you I would happily try and pair with you while you attempted it. You can make your Squeak VMMaker image first of course.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
cheers<br>
holger<br>
<br>
<br>
> 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).<br>
> <br>
> The reproducer is:<br>
> <br>
> StructA new theNest anyCall.<br>
> <br>
> <br>
> 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.<br>
> <br>
> I am not entirely sure how this is should work but what do you think of:<br>
> <br>
> 1st) Extending ExternalStructure class comment to list FFIExternalStructureReferenceHandle as possible handle type? I think we would only describe the reality.<br>
> <br>
> <br>
> 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?<br>
> <br>
> <br>
> comments/ideas?<br>
> <br>
> <br>
> <Unclassified.st><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div></div>