To do that the IDE calls a window API, to inject a int3.
<snip>
GDB does not understand/expect this.
So gdb will let the app execute the int3 => and that crashes. The app can also not catch it, because it happens in a thread the OS created for that.
Just a thought and, I don't really know if it would work but, might be worth a try. If instead of injecting an int 3 that neither GDB nor the app expect, _maybe_ suspending all the debuggee threads then have the IDE tell GDB to place the int 3 where desired. Since the debuggee is suspended, that _might_ work and the int 3 will no longer be unexpected by GDB (since it is there because _it_ placed it there.)
Suspending the threads is not going to help. While the app is running, gdb is in the "-exec-continue" command. And gdb will not accept any other commands until that finishes. So nothing can be send to gdb.
If you run gdb on a comand-line, you do ctrl-c and gdb will interrupt the app. But that does not work from the IDE. It did last on Win-95. (IIRC)
Gdb has an asynchronous command mode, where you could send the "interrupt" command (then gdb injects the int3). But that mode does only work with gdbserver, and some few special targets. Not on Windows.
You have to sent sent that int3.
Also, we have a working solution. The SVN 2.1 trunk IDE can run in 64bit, and use gdb to debug a 32bit target.
Further gdb will become more and more the option for remote debugging, embedded, and similar. Native (Win/Linux) will move to FpDebug.
-------
I just retested with gdb 9.2 => it still does not understand that code.
Gdb 10.1 introduces new errors when evaluating watches (watches that used to work, like "shortstring"). So I have not tested it. Would not help anyway.
There are rumours on stack overflow, that gdb 10 may have it fixed. But does not help, if it crashes on watches