Hi The following code crashes windows spur32 VM without crash.dmp: (crashes not only in case of int8, but ulong, int16/32 and so on...) Callback instantiation: createCallback C function: int8_t test(int8_t(*function)(int8_t), int8_t value) { FFI call: primCall: aCallback int8: aNumber Test case: test Windows 10. VM from today: Image 60343: P.S. what is the best place to report FFI / Alien issues? P.P.S Iceberg works Cheers, Alex |
On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
> Hi > > The following code crashes windows spur32 VM without crash.dmp: > (crashes not only in case of int8, but ulong, int16/32 and so on...) I don't think that Windows produces crash dumps (or they are empty files), but maybe you can find some info in Event Viewer (start>run "eventvwr.msc") in Event Viewer > Windows Logs > Application. > > Callback instantiation: > > createCallback > > ^ FFICallback > > signature: #(int8 (int8)) > > block: [ :value | value ] > > > C function: > > int8_t test(int8_t(*function)(int8_t), int8_t value) { > > return function(value); > > } > > > FFI call: > > primCall: aCallback int8: aNumber > > ^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber)) > > > Test case: > > test > > self > > assert: (self primCall: self createCallback int8: 0) > > equals: 0 > > > > Windows 10. > VM from today: > http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201701130756-83c0ef1.zip > Image 60343: > http://files.pharo.org/image/60/60343.zip > > P.S. what is the best place to report FFI / Alien issues? > P.P.S Iceberg works > > Cheers, > Alex |
Hi Peter, Latest windows VMs produce crash dumps ;) Cheers, Alex On 13 January 2017 at 10:57, Peter Uhnak <[hidden email]> wrote: On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote: |
On Fri, Jan 13, 2017 at 11:01:42AM -0800, Aliaksei Syrel wrote:
> Hi Peter, > > Latest windows VMs produce crash dumps ;) Excellent! :) Peter > > Cheers, > Alex > > On 13 January 2017 at 10:57, Peter Uhnak <[hidden email]> wrote: > > > On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote: > > > Hi > > > > > > The following code crashes windows spur32 VM without crash.dmp: > > > (crashes not only in case of int8, but ulong, int16/32 and so on...) > > > > I don't think that Windows produces crash dumps (or they are empty files), > > but maybe you can find some info in Event Viewer (start>run "eventvwr.msc") > > in Event Viewer > Windows Logs > Application. > > > > > > > > Callback instantiation: > > > > > > createCallback > > > > ^ FFICallback > > > > signature: #(int8 (int8)) > > > > block: [ :value | value ] > > > > > > > > > C function: > > > > > > int8_t test(int8_t(*function)(int8_t), int8_t value) { > > > > return function(value); > > > > } > > > > > > > > > FFI call: > > > > > > primCall: aCallback int8: aNumber > > > > ^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber)) > > > > > > > > > Test case: > > > > > > test > > > > self > > > > assert: (self primCall: self createCallback int8: 0) > > > > equals: 0 > > > > > > > > > > > > Windows 10. > > > VM from today: > > > http://files.pharo.org/vm/pharo-spur32/win/pharo-win- > > i386-201701130756-83c0ef1.zip > > > Image 60343: > > > http://files.pharo.org/image/60/60343.zip > > > > > > P.S. what is the best place to report FFI / Alien issues? > > > P.P.S Iceberg works > > > > > > Cheers, > > > Alex > > > > |
UPD: Works using 497 windows vm: http://files.pharo.org/vm/pharo-spur32/win/497.zip. Something was changed recently... Cheers, Alex On 13 January 2017 at 11:20, Peter Uhnak <[hidden email]> wrote: On Fri, Jan 13, 2017 at 11:01:42AM -0800, Aliaksei Syrel wrote: |
UPD: Works with latest Mac VM http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-201701130756-83c0ef1.zip Cheers, Alex On 13 January 2017 at 20:43, Aliaksei Syrel <[hidden email]> wrote:
|
UPD:
OS-Window and SDL bindings do not work on Mac VM (pharo-mac- On 13 January 2017 at 22:30, Aliaksei Syrel <[hidden email]> wrote:
|
In reply to this post by Aliaksei Syrel
Hi Aliaksei,
|
I've reproduced the crash in squeak.stack.spur Win32 with latest vm sources (SHA aa11221d9ebb5d60b0b88a2f1f8e27f19909d718) This crashing VM is compiled with gcc via ./mvm -f The Win64 version passes correctly. But it is compiled with clang by default. The Win32 compiled with clang also passes correctly for me. The test is translated in pure Alien for purpose of testing on Squeak 5.0 (see instructions below). -------------------------------------------------------------- from cygwin (or cygwin64) shell: $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ i686-w64-mingw32-clang --version clang version 3.8.1 (tags/RELEASE_381/final) Target: i686-w64-windows-gnu Thread model: posix InstalledDir: /usr/bin $ x86_64-w64-mingw32-clang --version clang version 3.8.1 (tags/RELEASE_381/final) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: /usr/bin -------------------------------------------------------------- $ cd build.win32x86/squeak.stack. $ ./mvm -f -- CC=i686-w64-mingw32-clang or for 64 bits: $ cd build.win64x64/squeak.stack. $ ./mvm -f-------------------------------------------------------------- $ cat >test.c << END END#include "stdint.h" int8_t test(int8_t(*function)(int8_t) return function(value); } $ i686-w64-mingw32-clang -c test.c $ i686-w64-mingw32-clang -shared -o build/vm/test.dll test.o $ build/vm/Squeak.exe -------------------------------------------------------------- then from Smalltalk image with Alien properly loaded (Alien-eem.39): <signature: #(int8 (*)(int8))> ^callbackContext wordResult: (block value: (regsAlien signedCharAt: 1) asInteger) (for now, above method must be compiled in each Callback subclass since we do not ask Pragma to scan superclass for signatures) TestCase subclass: #AlienCallbackSunit instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Alien-CoreTest' AlienCallbackSunit>> ^Callback signature: #(int8 (*)(int8)) block: [ :value | value ] AlienCallbackSunit>>primCall: aCallback int8: aNumber | r | (Alien lookup: 'test' inLibrary: 'test.dll') primFFICallResult: (r := Alien new: 1) with: aCallback thunk with: aNumber. ^(r signedCharAt: 1) asInteger AlienCallbackSunit>>test self assert: (self primCall: self createCallback int8: 0) equals: 0 2017-01-14 2:53 GMT+01:00 Eliot Miranda <[hidden email]>:
|
Hi Nicolas, Hi Esteban, so is it feasible to insist on clang? The mingw compiler is ancient, so my preference is to move to clang. If so, could someone update the HowToBuild to describe the problem with mingw and how to install the clang-based toolchain? On Tue, Jan 17, 2017 at 6:47 AM, Nicolas Cellier <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
> On 17 Jan 2017, at 19:43, Eliot Miranda <[hidden email]> wrote: > > Hi Nicolas, Hi Esteban, Hi all, > > so is it feasible to insist on clang? The mingw compiler is ancient, so my preference is to move to clang. If so, could someone update the HowToBuild to describe the problem with mingw and how to install the clang-based toolchain? > from cygwin (or cygwin64) shell: > > $ i686-w64-mingw32-gcc --version > i686-w64-mingw32-gcc (GCC) 5.4.0 > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. maybe I am missing something but GCC 5.4 was released in Summer 2016 and is still supported. Couldn't it be that the better optimizers in GCC expose an issue that clang is not capable of exposing (yet?)? just my two cents holger |
2017-01-17 19:49 GMT+01:00 Holger Freyther <[hidden email]>:
Hi Holger, maybe... One should compile with -O0 to check if it's really about optimization and retry if it solves anything. If yes, then play the game of selecting each individual optimization option. What I know is that the mingw version of gcc have strange stack management
with bytes reserved below alloca which is causing some complications in our
implemenation of FFI.Personnally I don't have a clue of the reason behind the difference with linux gcc, so without further information, I tend to perceive such differences as a useless and never-ending-source of complications. I'm speaking for myself, but maybe Eliot has the same feeling. Not sure that it's a great choice to abandon gcc support, but it's quite tempting in those circumstances ;) |
Free forum by Nabble | Edit this page |