2016-07-28 1:38 GMT+02:00 Ben Coman btc@openinworld.com:
On Thu, Jul 28, 2016 at 1:36 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2016-07-27 5:22 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice@gmail.com>:
Hi, I merged the changes from Tobias too fast... Despite the efforts, the win32 VM produced from HEAD are currently not
usable when compiled thru cygwin/mingw
I don't get a better health thru MSVC
The last functional VM I get (both win32 squeak.cog.spur and win64
squeak.stack.spur) are from
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/43dca8fe50b7cc70901...
This prevents me to focus on the VMaker LLP64 changes. Maybe we'll have to revert... Thoughts?
Nicolas
follow up: more than 20 commits after the merge, we did not yet recover
win32 health.
win32 squeak.stack.spur segfaults with no usefull clue
$ builddbg/vm/Squeak ../../image/trunk50.image Segmentation fault
$ gdb builddbg/vm/Squeak GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html%3E
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from builddbg/vm/Squeak...done. (gdb) run ../../image/trunk50.image Starting program:
/cygdrive/C/Users/cellier/Documents/Smalltalk/OpenSmalltalk/opensmalltalk-vm/build.win32x86/squeak.stack.spur/builddbg/vm/Squeak ../../image/trunk50.image
[New Thread 33724.0xf038] warning: `/cygdrive/c/windows/SYSTEM32/ntdll.dll': Shared library
architecture i386:x86-64 is not compatible with target architecture i386.
Probably incidental to the problem, but it seems its best to use 32bit gdb on 32bit programs. Maybe good to minimize interference.
http://virtuallyfun.superglobalmegacorp.com/2015/10/04/32bit-64bit-gdb-colli... http://stackoverflow.com/questions/12205256/gdb-failing-in-eclipse
cheers -ben
yes of course you're right, the gdb does not even reach a breakpoint in main (WinMain, sqMain, whatever). I'll see if there's an instance of i686-w64-mingw32-gdb.