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

David T. Lewis lewis at mail.msen.com
Fri Dec 31 17:12:55 UTC 2010


On Fri, Dec 31, 2010 at 04:56:48PM +0100, Igor Stasenko wrote:
> 
> 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)?
> 

Ha! And you thought that OSPP did not have any ugly hacks in it?
Wait till you see what I did to make forkSqueak work ;) ;)

> 
> 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
> creating.
> 

Possibly so, although OSProcess provides a more general facility for
hooking up any OS signal to a semaphore. You can activate the
handler from the image, and restore it back to default from the
image also. Anything that hard codes signal assignments in the VM
is a Very Bad Idea, and setting up something to do the assignments
from command line arguments would probably be messy. So if someone
needs to be able to activate printing stacks while debugging some
problem, then turn off the feature later, using OSProcess is a
good way to do it. Furthermore, if someone decides to use SIGUSR1
and SIGUSR2 for other purposes, you can just pick a different signal
number to use while you debug your problem.

Actually I think that Eliot did wire up SIGUSR1 to dump stacks in
Cog, but that's going to be a problem if someone needs SIGUSR1 for
some other purpose (e.g. some library linked in to the VM in a
plugin, where the external library relies on SIGUSR1 for some
other purpose).

Dave

> 
> 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
> ./platforms/win32/plugins/FontPlugin/sqWin32FontPlugin.c:
> 
> theSTWindow = (HWND*) interpreterProxy->ioLoadFunctionFrom("stWindow","");
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.


More information about the Vm-dev mailing list