Some background:
The problem we are facing is that (IIRC) there was some change in the Windows API, few years back. (Hence the problem now also affects all older versions of Lazarus)
It had been possible, for Lazarus to start a 64bit or 32bit gdb, matching the target project. And that gdb could then debug away, and the IDE talk to that gdb.
But, gdb can not receive a "pause request" from the IDE while the app is running. The IDE however needs to send that request, when:
- the pause button is pressed
- blue gutter dots need to be loaded (source tab changed)
- a breakpoint gets added/removed/changed (except at start-up)
That is done by calling the Windows API. Gdb then gets a notification by Windows, which gdb handles.
But when a 64 bit process calls the debugging API for a 32 bit (WOW) process, then the signal's number changed. And gdb no longer understands it. And hence all cross debugging was suddenly broken.
In Lazarus trunk/2.1 there is code to start a 32bit helper process to call the windows API, and that will work.
In gdb 10, things got patched up in gdb. So gdb 10 should work. But gdb10 has some other issues (and it may be you a hitting one of them).
I have (for windows) more than a dozen 32bit gdb, and equally many 64bit gdb on my system, for testing.
Unfortunately I am very short on time for that testing.
I also have (thanks to a user on the forum) a patch to gdb, that may solve an unrelated issue. Again I need to find the time to test....
In Lazarus trunk, the helper app should allow debugging with a better tested version of gdb 8.2, or one of the cygwin builds (or eventually the patched one)
Still gdb in any version (tested from 6.7 to 10.1) has issues with fpc executables. Sometimes crashes, sometimes that it can not display the data.
Part of that are issues in gdb, some few cases are caused by fpc.
So we have a new debugger, no gdb involved: FpDebug / package LazDebuggerFp.
There is a version of it in 2.0.x, but for cross-bitness debugging you need trunk.