[Vm-dev] Simulating FFI Calls [was Re: VMMaker simulation - strlen, strcpy, getenv and FakeStdinStream]

Eliot Miranda eliot.miranda at gmail.com
Sun Oct 14 23:21:28 UTC 2018

On Sun, Oct 14, 2018 at 1:03 PM Alistair Grant <akgrant0710 at gmail.com>

> Hi All,
> Just in case there aren't automatic notifications of submissions to
> VMMakerInbox...
> I've submitted the following changes (more information after the
> descriptions):
> Name: VMMaker.oscog-AlistairGrant.2455
> Author: AlistairGrant
> Time: 14 October 2018, 8:59:01.383815 pm
> UUID: 9e8e4134-b30b-4734-9477-95d556650155
> Ancestors: VMMaker.oscog-eem.2454
> VMClass strlen, strncpy and getenv
> Pharo stores UTF8 encoded strings in ByteArrays (ByteString, strictly
> speaking, expects to only store characters that can be represented as
> a single byte in UTF8, e.g. ascii).  ByteArrays are also used within
> the simulator to represent buffers allocated by the simulator.  As
> such, the strings may either be the length of the ByteArray or less
> than the ByteArray size and null terminated.
> These changes extend strlen: and strncpy:_:_: to handle ByteArrays and
> add some tests (tests for strings in the object memory are todo).
> InterpreterPrimitives>>primitiveGetenv: returned nil rather than 0 in
> the simulator when a variable that isn't defined is requested.
> Name: VMMaker.oscog-AlistairGrant.2456
> Author: AlistairGrant
> Time: 14 October 2018, 9:25:11.249348 pm
> UUID: 47b0319d-df10-4ece-84fc-324d0d35fe1d
> Ancestors: VMMaker.oscog-AlistairGrant.2455
> FakeStdinStream and FilePluginSimulator do double duty with the #atEnd
> flag to allow #sqFile:Read:Into:At: to break out of its loop.  This is
> brittle as a additional calls to #atEnd breaks the simulation - which
> is what Pharo does.
> Instead of doing double duty with #atEnd, do the same as the actual
> plugin (sqFileReadIntoAt() in sqFilePluginBasicPrims.c) and ignore the
> number of bytes to read when input is from stdin (FakeStdinStream) and
> only ever read a single byte (fixes the problem and is closer to the
> real plugin behaviour).
> Background:
> I've successfully got a Pharo 7 image (with FileAttributesPlugin)
> running StdioListener in the VM simulator, but have made a few changes
> at each level:
> - Created a modified Pharo image that avoids FFI:
> -- It doesn't load FreeType fonts or Iceberg to avoid FFI callouts.
> -- Uses UnixOSProcessPlugin>>primitiveGetCurrentWorkingDirectory
> instead of an FFI callout.
> - StdioListener has changes to work with Zinc streams
> - VMMaker has changes (in addition to the patches above):
> -- Added UnixOSProcessPluginSimulator so that
> primitiveGetCurrentWorkingDirectory can be used instead of FFI.
> Can someone tell me whether FFI is expected to work within the simulator?

As yet no.  But in theory it may be possible.  If you look at the way in
which primitives are dispatched in the simulator (dispatchFunctionPointer:)
that could be used to implement FFI calls (although not particularly
safely).  I have written
in such a way that the call could be simulated (when I added support for
PrimErrFFIException).  Simulating
would require invoking an FFI call itself (i.e. via
ExternalFunction>>invokeWithArguments:) to do the actual call-out.  But too
do that we would need a derived pointer type, so that e.g. an address in
the heap (SpurMemoryManager/ObjectMemory memory inst var) could be passed
as an argument; such an address is an offset to the memory ByteArray.  So
we're close, but still need some infrastructure (and derived pointers are
generally useful anyway).

Clearly such an implementation is unsafe; but increasingly we will need to
simulate FFI calls if the simulator is to continue being useful.

> Alistair

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181014/8ff7f464/attachment.html>

More information about the Vm-dev mailing list