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
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
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. warning: `/cygdrive/c/windows/SYSTEM32/wow64.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386. warning: `/cygdrive/c/windows/SYSTEM32/wow64win.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386. warning: `/cygdrive/c/windows/SYSTEM32/wow64cpu.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386. warning: dll path for "WOW64_IMAGE_SECTION" can not be evaluated warning: Could not load shared library symbols for WOW64_IMAGE_SECTION. Do you need "set solib-search-path" or "set sysroot"? warning: dll path for "WOW64_IMAGE_SECTION" can not be evaluated warning: Could not load shared library symbols for WOW64_IMAGE_SECTION. Do you need "set solib-search-path" or "set sysroot"? warning: dll path for "NOT_AN_IMAGE" can not be evaluated warning: Could not load shared library symbols for NOT_AN_IMAGE. Do you need "set solib-search-path" or "set sysroot"? warning: dll path for "NOT_AN_IMAGE" can not be evaluated warning: Could not load shared library symbols for NOT_AN_IMAGE. Do you need "set solib-search-path" or "set sysroot"? [New Thread 33724.0xf788] [New Thread 33724.0xe26c]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 33724.0xe26c] 0x0000002b in ?? () (gdb) where #0 0x0000002b in ?? () #1 0xab750062 in ?? () #2 0x006c0069 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb)
-------------------------------------------------------------------------------------
win64 squeak.stack.spur fails sooner in CreateWindowEx where we open the consoleWindow
------------------------------------------------------------------------------------- $ builddbg/vm/Squeak ../../image/trunk50-64-15711.image
CELLIER ~/Documents/Smalltalk/OpenSmalltalk/opensmalltalk-vm/build.win64x64/squeak.stack.spur
$ gdb builddbg/vm/Squeak ...snip... Reading symbols from builddbg/vm/Squeak...done. (gdb) run ../../image/trunk50-64-15711.image Starting program: /cygdrive/C/Users/cellier/Documents/Smalltalk/OpenSmalltalk/opensmalltalk-vm/build.win64x64/squeak.stack.spur/builddbg/vm/Squeak ../../image/trunk50-64-15711.image [New Thread 67440.0x100d4] warning: dll path for "C:\windows\system32\kernel64.dll" can not be evaluated warning: Could not load shared library symbols for C:\windows\system32\kernel64.dll. Do you need "set solib-search-path" or "set sysroot"? warning: Critical error detected c0000374
Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000076e4f230 in ntdll!RtlUnhandledExceptionFilter () from /cygdrive/c/windows/SYSTEM32/ntdll.dll (gdb) where #0 0x0000000076e4f230 in ntdll!RtlUnhandledExceptionFilter () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #1 0x0000000076e4f846 in ntdll!EtwEnumerateProcessRegGuids () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #2 0x0000000076e50412 in ntdll!RtlQueryProcessLockInformation () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #3 0x0000000076e52084 in ntdll!RtlLogStackBackTrace () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #4 0x0000000076e52468 in ntdll!RtlLogStackBackTrace () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #5 0x0000000076dfc9c4 in ntdll!TpAlpcRegisterCompletionList () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #6 0x0000000076dddba8 in ntdll!RtlAllocateHeap () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #7 0x0000000076e618dd in ntdll!EtwEventWriteStartScenario () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #8 0x0000000076dfc7cd in ntdll!TpAlpcRegisterCompletionList () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #9 0x0000000076dddba8 in ntdll!RtlAllocateHeap () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #10 0x000007feff0013d2 in msvcrt!malloc () from /cygdrive/c/windows/system32/msvcrt.dll #11 0x000007fefb4ac15f in UxTheme!IsThemePartDefined () from /cygdrive/c/windows/system32/UxTheme.dll #12 0x000007fefb4abaca in UxTheme!IsThemePartDefined () from /cygdrive/c/windows/system32/UxTheme.dll #13 0x000007fefb4abc63 in UxTheme!IsThemePartDefined () from /cygdrive/c/windows/system32/UxTheme.dll #14 0x0000000076dc6a98 in ntdll!TpAllocTimer () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #15 0x0000000076dc686e in ntdll!TpAllocTimer () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #16 0x0000000076db5fcf in ntdll!LdrLoadDll () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #17 0x000007fefce00176 in TlsGetValue () from /cygdrive/c/windows/system32/KERNELBASE.dll #18 0x000007fefcdec7a1 in LoadLibraryExA () from /cygdrive/c/windows/system32/KERNELBASE.dll #19 0x000007fefb51fcf2 in ?? () from /cygdrive/c/windows/WinSxS/amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757/COMCTL32.dll #20 0x000007fefb68cf79 in DllGetVersion () from /cygdrive/c/windows/WinSxS/amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757/COMCTL32.dll #21 0x000007fefb5a9694 in TaskDialog () from /cygdrive/c/windows/WinSxS/amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757/COMCTL32.dll #22 0x000007fefb5706e0 in TaskDialog () from /cygdrive/c/windows/WinSxS/amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757/COMCTL32.dll #23 0x000007fefb5a9cc2 in TaskDialog () from /cygdrive/c/windows/WinSxS/amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757/COMCTL32.dll #24 0x0000000076ca9c11 in USER32!TranslateMessageEx () from /cygdrive/c/windows/system32/USER32.dll #25 0x0000000076ca72f7 in USER32!SetWindowTextW () from /cygdrive/c/windows/system32/USER32.dll #26 0x0000000076ca0781 in USER32!SendMessageTimeoutW () from /cygdrive/c/windows/system32/USER32.dll #27 0x0000000076ddba75 in ntdll!KiUserCallbackDispatcher () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #28 0x0000000076ca040a in USER32!SendMessageTimeoutW () from /cygdrive/c/windows/system32/USER32.dll #29 0x0000000076ca0387 in USER32!SendMessageTimeoutW () from /cygdrive/c/windows/system32/USER32.dll #30 0x0000000076ca05c8 in USER32!SendMessageTimeoutW () from /cygdrive/c/windows/system32/USER32.dll #31 0x0000000076c9a324 in USER32!CreateWindowExA () from /cygdrive/c/windows/system32/USER32.dll #32 0x00000000004d881d in SetupWindows () at ../../platforms/win32/vm/sqWin32Window.c:979 #33 0x00000000004d0fc0 in sqMain (argc=2, argv=0x226f40) at ../../platforms/win32/vm/sqWin32Main.c:1535 #34 0x00000000004d1b85 in WinMain (hInst=0x400000, hPrevInstance=0x0, lpCmdLine=0x2e5508 "../../image/trunk50-64-15711.image", nCmdShow=10) at ../../platforms/win32/vm/sqWin32Main.c:1780 #35 0x00000000004013e8 in __tmainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-4.0.6-1/crt/crtexe.c:332 #36 0x00000000004014eb in WinMainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-4.0.6-1/crt/crtexe.c:184 (gdb)
-------------------------------------------------------------------------------------
If I comment this call, (replace with consoleWindow = NULL;) then it fails few steps later. It's just a symptom that we have broken something in the setup I searched refs to alloca - like we return or pass a dangling pointer to the local stack - unsuccessfully... It might be worth to try again thru MSVC IDE (complementary warnings, stack integrity checks, ...)
------------------------------------------------------------------------------------- warning: Critical error detected c0000374
Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000076e4f230 in ntdll!RtlUnhandledExceptionFilter () from /cygdrive/c/windows/SYSTEM32/ntdll.dll (gdb) where #0 0x0000000076e4f230 in ntdll!RtlUnhandledExceptionFilter () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #1 0x0000000076e4f846 in ntdll!EtwEnumerateProcessRegGuids () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #2 0x0000000076e50412 in ntdll!RtlQueryProcessLockInformation () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #3 0x0000000076e52084 in ntdll!RtlLogStackBackTrace () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #4 0x0000000076e52468 in ntdll!RtlLogStackBackTrace () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #5 0x0000000076dfc9c4 in ntdll!TpAlpcRegisterCompletionList () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #6 0x0000000076dddba8 in ntdll!RtlAllocateHeap () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #7 0x0000000076e618dd in ntdll!EtwEventWriteStartScenario () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #8 0x0000000076dfc7cd in ntdll!TpAlpcRegisterCompletionList () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #9 0x0000000076dddba8 in ntdll!RtlAllocateHeap () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #10 0x000007feff0014e4 in msvcrt!malloc () from /cygdrive/c/windows/system32/msvcrt.dll #11 0x000007feff0019ed in msvcrt!calloc () from /cygdrive/c/windows/system32/msvcrt.dll #12 0x00000000004d7647 in SetWindowTitle () at ../../platforms/win32/vm/sqWin32Window.c:743 #13 0x00000000004d8782 in SetupWindows () at ../../platforms/win32/vm/sqWin32Window.c:996 #14 0x00000000004d0fc0 in sqMain (argc=2, argv=0x1d6f40) at ../../platforms/win32/vm/sqWin32Main.c:1535 #15 0x00000000004d1b85 in WinMain (hInst=0x400000, hPrevInstance=0x0, lpCmdLine=0x1f5508 "../../image/trunk50-64-15711.image", nCmdShow=10) at ../../platforms/win32/vm/sqWin32Main.c:1780 #16 0x00000000004013e8 in __tmainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-4.0.6-1/crt/crtexe.c:332 #17 0x00000000004014eb in WinMainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-4.0.6-1/crt/crtexe.c:184
On 27.07.2016, at 19:36, 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
Ok, i'll branch out and feel free to revert to your good commit :) sorry for the noise
best regards -Tobias
On 27.07.2016, at 20:11, Tobias Pape Das.Linux@gmx.de wrote:
On 27.07.2016, at 19:36, 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
Ok, i'll branch out and feel free to revert to your good commit :) sorry for the noise
One more thing: as of 18243a6 (https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/18243a65b8d47740c48...) I have a non-segfaulting squeak/cog/spur-vm on windows. Maybe that's again a good baseline?
Again: sorry for the noise.
Best regards -Tobias
On 27.07.2016, at 21:02, Das.Linux@gmx.de wrote:
On 27.07.2016, at 20:11, Tobias Pape Das.Linux@gmx.de wrote:
On 27.07.2016, at 19:36, 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
Ok, i'll branch out and feel free to revert to your good commit :) sorry for the noise
One more thing: as of 18243a6 (https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/18243a65b8d47740c48...) I have a non-segfaulting squeak/cog/spur-vm on windows. Maybe that's again a good baseline?
Again: sorry for the noise.
scratch that :(
Best regards -Tobias
Hi Nicolas and all
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
Ok, i'll branch out and feel free to revert to your good commit :) sorry for the noise
I'm waiting for appveyor, but with 7e603e7, the revert should be as complete as possible, my changes are on a branch (krono/win32-second-try).
Sorry for the fuzz, I promise more rigor.
Best regards -Tobi
2016-07-27 22:52 GMT+02:00 Das.Linux@gmx.de:
Hi Nicolas and all
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
Ok, i'll branch out and feel free to revert to your good commit :) sorry for the noise
I'm waiting for appveyor, but with 7e603e7, the revert should be as complete as possible, my changes are on a branch (krono/win32-second-try).
Sorry for the fuzz, I promise more rigor.
Best regards -Tobi
Yes, it is far from an easy change ! I hope we'll see it back soon, more straight and uniform Unicode support is not an option :) Thanks Tobias
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 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
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.
On 28.07.2016, at 08:30, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
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.
I just installed gdb with the cygwin installer, that worked well… (but then again, I used the 32bit installer)
Best regards -Tobias
PS: tui enable was the most helpful gdb command in a long time for me
vm-dev@lists.squeakfoundation.org