[Vm-dev] argCnt, argVec, engVec alternatives

Igor Stasenko siguctua at gmail.com
Thu Jan 6 02:45:27 UTC 2011


On 6 January 2011 03:15, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>
> Hi,
>
> 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) :)
>

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

> Cheers,
> Esteban
>


-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list