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