[Vm-dev] Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

Igor Stasenko siguctua at gmail.com
Fri Dec 31 15:56:48 UTC 2010

On 31 December 2010 16:26, David T. Lewis <lewis at mail.msen.com> wrote:
> Hi Esteban,
> You have found a bug in OSProcessPlugin. One of the primitives was
> sending "self primitiveFail" where it should be "interpreterProxy
> primitiveFail".  I can't explain why this does not cause problems
> on Linux, but it is definitely a bug in my code, and thanks for finding
> it.
> The fix is in SqueakSource/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.25
> The printAllStacks() function is part of the interpreter, but it
> is not part of the interpreterProxy interface, so that it why it
> is an issue for linking. I'm afraid that I do not know anything
> about developing on a Mac, so I do not know if there is a possible
> workaround for this. I guess we could add it to the interpreterProxy
> interface, but I don't know if this is important for anyone, so
> maybe it will be best to just remove it from OSProcessPlugin.
> I expect that you will have similar issues with AioPlugin. On unix
> it is built as an external plugin, but it contains references to
> functions in the interpreter support code so you would probably
> need to build it as an internal plugin.

I think this is an abuse of dynamic linker.
A shared library should not have undefined symbols to be magically
bound later from unknown source.

What are guarantees that vm module will always have these functions?
What if i build the vm without printAllStacks as externally visible
function (and why i should not btw)?

The primitivePrintAllStacksOnSignal as to me belongs to VM core itself..
i think it would be better to move it to Interpreter code and remove
it from OSProcess plugin, thus avoiding external dependency it

As for:

>> >> #warning what about these guyes?
>> >> /*** Variables -- globals for access from pluggable primitives ***/
>> >> int                argCnt= 0;
>> >> char       **argVec= 0;
>> >> char       **envVec= 0;

these should be 'linked' through ioLoadFunction() interface,
and exposed by osXXXExports.c

see how its done for stWindow in platforms/win32/vm/sqWin32Exports.c
and then used in

theSTWindow = (HWND*) interpreterProxy->ioLoadFunctionFrom("stWindow","");

Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list