Hi Skeeto,

Big fan of your w64devkit!
Not many people develop on WinXP, I thought I would pick your brain
regarding an issue, I've had for years.

By any chance, do you use winXP in a VM  (VirtualBox,VMWare)
and use Eclipse IDE?
All the GDB's I've tried (11 down to 4) don't seem to get past the
GDB init phase in Eclipse, but GDB works fine via console.
I have firewall disabled.

I've also tried older versions of Eclipse, but with the same problem.
I would guess, the VM is affecting eclipse's port to GDB.
Strangely enough, I've had issues with GDB in modern linux with VB,
GDB doesn't work as expected with more then 1 breakpoints at launch.
I've tried searching, but it seems I'm in a very niche use case,
that I couldn't find anything that would help.
Any suggestions on where to look?

If you don't use Eclipse, which IDE do you use in winXP?

Cheers
Mike.

Yes, I run Windows XP in a VM, but no, I have little experience with 
Eclipse, and none running GDB through it. So, sorry, I can't help with 
Eclipse, and I don't know where to start looking.

> If you don't use Eclipse, which IDE do you use in winXP?

The same way I do anywhere else:

* Edit in Vim
* Build from Vim (:make, makeprg)
* Debug directly in GDB

During development I always run/test via GDB. I keep a long-running GDB 
session in a console, maintaining state (breakpoints, etc.) between runs. 
I use 'k' (kill) to stop the debuggee so that I can rebuild, avoiding 
Windows file locking. Then I test again with 'r' (run). I access Git from 
GDB using "!git" which I alias to 'g', so I don't need another console.

As generally true with debugging graphical applications, pressing F12 will 
pause the program in the attached debugger — a handy feature I miss on 
Linux. Similarly, w64devkit has a "debugbreak" command which pauses all 
debugee processes. I run it from Vim when needed. (On Linux you'd use a 
signal.)

The past few w64devkit releases have included GDB TUI support, though I 
don't always enable it. It's most handy when dealing with unfamiliar code. 
If console output is important such that you cannot redirect to NUL, set 
"new-console" so that it doesn't interfere with the TUI. I don't like the 
source pane having focus and stealing some inputs, so I typically "focus 
cmd". If you haven't tried GDB TUI, I encourage you to try it out! It gets 
better with each GDB release. That includes the next w64devkit, which will 
have GDB 13, with even more "downstream" w64devkit-only improvements.

General tips:

GDB has hardcoded special handling of wchar_t and char16_t (and char32_t), 
but not Windows types like WCHAR, so prefer the more standard types. In 
the worst case you can cast WCHAR to wchar_t in GDB so that it invokes the 
special handling and displays as a string.

In case you didn't know: Check out OutputDebugStringA. GDB receives and 
displays those messages, they don't interfere with the TUI since GDB is 
the one printing them, and unlike standard error it works with windows 
subsystem programs.

The MSVCRT assertion mechanism is awful, and GDB doesn't understand it, so 
it doesn't trap. Instead, write your own custom assertion macro using 
__builtin_trap. See my assertion article for details.

UBSan is supported in Mingw-w64, but not with libubsan. So instead use 
-fsanitize-undefined-trap-on-error to insert traps without diagnostics, 
which work very nicely in GDB. When possible, it will even insert bounds 
checks on array indexing.

That's everything that comes to mind right now. I'm quite comfortable 
debugging directly in GDB without any special front-end.

A whole different option: Visual Studio 2008. It's my favorite version, 
and VS has overall gone downhill ever since. It works well on XP. I still 
edit in Vim, but I build via the command line tools (vcvarsall.bat), and 
debug using Visual Studio (devenv) since it's a good debugger. No RemedyBG 
for XP, sadly. Downside: While it's from 2008, C support is still stuck in 
1989, which is why so many people got into the habit of using C++ despite 
writing it just like C. They mostly wanted quality of life features like 
declare anywhere, and not really C++.