[Vm-dev] Win32 Squeak.cog.spur FFI failure

[Nicolas Cellier]

2016-11-08 1:39 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> So win32 FFI test crash the VM if compiled with gcc.
> But tests pass if compiled with clang (i686-w64-mingw32-clang on cygwin64)
>
>
Argh, tests pass only if compiled with clang in debug mode (mvm -d)...
mvm -f CC=i686-w64-mingw32-clang will also crash the VM and make some other
tests fail.
Not having the debug version failing means having to debug optimized code
at assembler level. Super Argh!

---------------- details following -----------------
>
> The problem with gcc is the famous ALLOCA_LIES_SO_USE_GETSP
> Indeed, alloca reserve 16 more bytes than necessary. That is, it answers a
> value, but increment
>     stack pointer = return alloca'd + 16
> It's wrong because we want to pile up FFI args starting at stack pointer,
> just above the future return address.
>
> So there is a hack in code generation that used to workaround the problem:
> use SP instead of alloca'd value for marshalling FFI args.
> Unfortunately as we could have guessed it was fragile...
> Recent versions of gcc do use the 16 extra bytes !!!
> Indeed it seems that the function calls that are used for marshalling FFI
> arguments will use SP,SP+4,SP+8 and SP+12 for their own arguments, without
> incrementing SP first
> Thus when we try and fill the FFI argument stack, we break the own stack
> of these functions... Since most of these arguments are pointers (oops and
> calloutState), then we very soon SEGV.
>
> 2016-08-19 19:05 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>>
>>
>> 2016-08-19 18:29 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>> l.com>:
>>
>>> Hi,
>>>
>>> Win32 FFI fails for some time now.
>>> For example, load latest versions of FFI from
>>> http://source.squeak.org/FFI
>>> Then try this snippet:
>>>
>>> FFIPluginTests new testGenericDoubleCall.
>>>
>>> And you'll get a segmentation fault, crash.dmp.
>>> The latest vmI found in bintray already has the problem.
>>>
>>
>> Hem, the oldest VM, not the latest
>>
>>
>>> https://dl.bintray.com/opensmalltalk/vm/:cog_win32x86_squeak
>>> .cog.spur_201606301459.zip
>>>
>>> This bug delayed the Win64 squeak.stack.spur delivery, because I thought
>>> I introduced a regression somewhere...
>>>
>>> I did not have time to check other OSes, but it would be worth trying.
>>> (Before declaring any VM+plugins as stable...)
>>>
>>> If someone has a way to easily dissect without precompiled artifacts,
>>> let me know.
>>>
>> err, bissect not dissect
>>
>>
>>>
>>> Nicolas
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161108/cd8128cb/attachment.html>