Created attachment 9770 [details]
config.log file from configure run
I have built the latest gdb (7.12.1) with i686-w64-mingw32 (gcc v6.3.0, MSYS2) on a Windows 7 64bit system, simply using
(I attached the config.log to this report.)
When I start gdb and enter any invalid command that would normally lead to an error message (like "help foobar"), the process just aborts (like from an unhandled exception):
(gdb) help foobar
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Version 7.12 has the same problem, but 7.11 works fine, so this must be triggered by something since 7.11. I also tried building with the old mingw gcc from mingw.org, but it has the same problem. Unfortunately, I cannot seem to be able to obtain any backtrace when running this inside another gdb.
I also tried other gdb v7.12 binary builds, and some have the same problem, for instance the gdb in the latest Linaro toolchain for Arm, or the 'gdb' that can be installed in MSYS2. However, the build from Eli Zaretskii (ezwinports) works fine.
Looks like a C++ exception is thrown by error(), but it is not catched in catch_errors().
5 throw_exception_cxx common-exceptions.c 303
6 throw_exception common-exceptions.c 317
7 throw_it common-exceptions.c 373
8 throw_verror common-exceptions.c 379
9 verror utils.c 525
10 error errors.c 43
11 undef_cmd_error cli-decode.c 1475
12 lookup_cmd cli-decode.c 1517
13 execute_command top.c 630
14 command_handler event-top.c 641
15 command_line_handler event-top.c 833
16 gdb_rl_callback_handler event-top.c 213
17 rl_callback_read_char callback.c 220
18 gdb_rl_callback_read_char_wrapper_noexcept event-top.c 175
19 gdb_rl_callback_read_char_wrapper event-top.c 192
20 stdin_event_handler event-top.c 568
21 handle_file_event event-loop.c 733
22 gdb_wait_for_event event-loop.c 884
23 gdb_do_one_event event-loop.c 347
24 gdb_do_one_event common-exceptions.h 225
25 start_event_loop event-loop.c 371
26 captured_command_loop main.c 324
27 catch_errors exceptions.c 236
28 captured_main main.c 1149
29 gdb_main main.c 1159
30 main gdb.c 32
Actually the exception should be catched in gdb_rl_callback_handler.
Linking without -static-libstdc++ and -static-libgcc fixes this. There's a pending patch in bug 21187.
I just built using the current master, using GCC 6.3.1, and it worked fine for me:
(top-gdb) help foobar
Undefined command: "foobar". Try "help".
I just tested again with gdb 8.0 and gcc 6.3.0 from MSYS2 32bit (i686-w64-mingw32-gcc), and I still see the same problem. I have no idea why it works for you.
I can however also confirm that the patch from Orgad in bug 21187 and using "--disable-staticlib" fixes this issue, so it is definitely an issue with static linking.
This problem is also seen on x86 Cygwin, and same workaround applies.
It would be nice if we understood what was going wrong in the unwinder to cause this problem, though...
I don't see this issue, I build GDB git master under msys + mingw-w64 mingw-build 5.4 gcc 32 bit version, if you would like to test, I have the binary here: http://forums.codeblocks.org/index.php/topic,22185.0.html, you need to install the official python 2.7 distribution, because my gdb was build against this python.
(In reply to asmwarrior from comment #7)
> I don't see this issue, I build GDB git master under msys + mingw-w64
> mingw-build 5.4 gcc 32 bit version, if you would like to test, I have the
> binary here: http://forums.codeblocks.org/index.php/topic,22185.0.html, you
> need to install the official python 2.7 distribution, because my gdb was
> build against this python.
Since it seems to be something to do with unwinding across DLL boundaries, I'm going to wildly guess that building without --with-system-readline also prevents
I've also just come across this on 32-bit Cygwin.
Strangely, gdb 8.0 is fine, when compiled with gcc 6.4.0 and 7.3.0.
However, gdb 8.1 and 8.1.1 both have the problem, when compiled with gcc 6.4.0 or 7.3.0.
Removing -static-libstdc++ -static-libgcc LDFLAGS fixes it as above.