[Vm-dev] argCnt, argVec, engVec alternatives

David T. Lewis lewis at mail.msen.com
Thu Jan 6 03:06:18 UTC 2011


On Thu, Jan 06, 2011 at 03:45:27AM +0100, Igor Stasenko wrote:
> 
> On 6 January 2011 03:15, Esteban Lorenzano <estebanlm at gmail.com> wrote:
> >
> > El 05/01/2011, a las 10:56p.m., David T. Lewis escribi??:
> >
> >> On Wed, Jan 05, 2011 at 03:30:19PM -0300, Esteban Lorenzano wrote:
> >>>
> >>> ok... removing call to printAllStack in plugin and adding initialization
> >>> of argCnt, argVec and engVec (plus the changes made last week),
> >>> UnixOSProcessPlugin, without AioPlugin, is running in Cocoa Cog VM :D
> >>
> >> Excellent!
> >>
> >>> I would like to commit a OSProcessPlugin package with modifications...
> >>> or well, maybe project owner can do this changes for me (I just removed
> >>> primitivePrintAllStacksOnSignal, printAllStacksFunctionAddress and
> >>> printAllStacksOnSignal).
> >>>
> >> Actually, if you don't mind working with me on this a bit more, I'd
> >> like to debug it. I suspect we can can make this work on Cocoa.
> >>
> >> We know now that external plugins can access global values such
> >> as argVec and interpreterProxy, and we know that this works the
> >> same on Unix and Mac. The last thing that is giving us problems
> >> is when primitivePrintAllStacksOnSignal tries to access the address
> >> of the function printAllStacks(). This happens here in the plugin:
> >>
> >> ??static void * printAllStacksFunctionAddress(void) {
> >> ?? ?? ??extern sqInt printAllStacks();
> >> ?? ?? ?? ?? ??return printAllStacks;
> >> ??}
> >>
> >> So the declaration looks right, but apparently accessing the
> >> address of a global function is not the same as accessing the
> >> value of a global variable, and perhaps this is a difference
> >> between the Unix/Linux systems and Mac.
> >>
> >> So I am guessing that if, in the support code, we were to assign
> >> the function address to a global variable, then the plugin would
> >> be able to access it, and #primitivePrintAllStacksOnSignal would
> >> work properly.
> >>
> >> If this sounds like it might be right, I'll try to think of a way
> >> to implement it without breaking the existing unix implementations.
> >
> >
> > yes, that would work. In fact, declaring printAllStacks() as:
> >
> > EXPORT(sqint) printAllStacks();
> >
> > ... works too. And even adding setting -fvisibility=default (which exports ALL symbols) will work too. But I think the last one is a little bit too much: visibility=default is default for plain gcc compiler, but not un mac now (I think that's the reason why it was working before and not now) :)
> >

Esteban, thanks. It's obvious now that you point it out. I added
the <export: true> to Interpreter>>printAllStacks in VMMaker trunk.

> 
> So, how it works for Squeak VM, where #printAllStacks is listed in
> #requiredMethodNames,
> which meand that generator should always retain this method in source code,
> but it is not means that printAllStacks symbol is visible to external
> module(s).. I mean the declaration is just:
> sqInt printAllStacks(void);
> 
> Doesn't symbols should be marked for export to make them visible
> externally? Or on unix systems its not necessary?
> 
> Ah.. -fvisibility=default explains this.
> 
> Heh.. but then out of curiosity,  why do we need to use
> interpreterProxy struct, while plugins can just use any VM function(s)
> directly,
> even through dynamic linking?
> 
> Okay, in Cog this function marked as a part of api.

So is the problem already resolved in Cog, or do we need to add
an <export: true> in Cog also?

> But i don't understand why then we using two different ways to access
> VM functionality from external modules?
> 
> There should be either interpreterProxy or symbols export mechanism ,
> but not both, because they are obviously overlap.

I miss Tim Rowledge on this list. If he were here, he would step in
right now to remind us that not all computers in the universe are
running Unix ;)

Dave



More information about the Vm-dev mailing list