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?
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
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.
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
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++.