[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