[Vm-dev] 64-bit plugin support

David T. Lewis lewis at mail.msen.com
Thu Apr 2 01:56:16 UTC 2015


On Wed, Apr 01, 2015 at 10:16:37PM +0200, Nicolas Cellier wrote:
>  
> Hello,
> I noticed a few #positive32BitValueOf: usage in plugins for the purpose of
> retrieving a pointer stored in a #sqInt or #usqInt.

That would definitely be wrong. Any plugin that stores machine pointers in
sqInt or usqInt is broken.

There are number of plugins that are still not updated for 64-bit VMs. I've
tried to track some of the status of this on bugs.squeak.org although the
information is not complete.

Of the top of my head, I think that the SSL plugin, Camera plugin, anything
dependent on SurfacePlugin, and probably a few others are broken. FFIPlugin
was notably broken (with the fixes are on Mantis but not integrated), though
that my no longer be relevant with newer FFI plugins.

> 
> Yes, a #sqInt is large enough to hold a pointer, but shouldn't it be filled
> with positiveMachineIntegerValueOf:?
> At least this is necessary for spur64.

A sqInt is *not* large enough to hold a pointer, specifically in the most
common case of a 32-bit object memory running on a 64-bit interpreter VM.

> 
> Here are 3 patches attached.
> 
> Nicolas

Thanks! I know your patches are focused on Spur but I'll try running them also on
the interpreter VM as soon as I am able. Note that positiveMachineIntegerValueOf:
is a Spur idiom, although I would not expect that it would necessary to rely on that,
since usually just declaring the variables correctly is sufficient. So for example in
QuicktimePlugin>>primitiveSetGWorldPtrOntoSurface:width:height:rowBytes:depth:movie:
there is a variable #buffer that looks like it needs to be a (char *), but is undeclared
and takes the default #sqInt. Casting it to (char *) will always fail in the case of
a 32-bit sqInt on a 64-bit host platform, regardless of which idiom you use in the
cCoerce cast. It is better to declare both #buffer and #bitMapPtr explicitly, and
get rid of the cast. That usually requires also fixing up the declarations in the
support code and header files in ./Cross, but that's probably the only way to get
it right.

Dave



More information about the Vm-dev mailing list