Hacker News Reader

Comment by brtkdotse | Hacker News Reader

Having spent my entire career inside of Visual Studio (nee VS Code), this strikes me as a quaint relic from a time past.

Can it be powerful? Probably. But the dev experience looks terrible.

View on HN

Microsoft makes an excellent debugger. One advantage gdb has, though, is that you can attach it to almost any process over a terminal. Another (that I've seen used to great effect, but not since a long time ago) is that it's very straightforward to build up powerful libraries of debugging scripts—things like dumping or following custom data structures, which can be really useful for core file analysis and what not.

VS debugger can do none of the things I look to a debugger to do.

Dev experience is fixable in many ways, but wholesale lack of capability is not.

VSCode is really frustrating lately, I debug all day long and the IDE just randomly shits a brick, or hangs, or just stalls, the vim plugin just loses its shit once in a while do ruining your undo's.

MSVC was (is) by far much better overall (I only pull it out now a days to analyze crash dumps though). Heck in vscode you can't really see variables in C++ or examine memory, or set memory change break points, but really 90% of developing doesn't require any of that, so vscode just keeps growing in use.

I do love me some GDB though, when I'm developing on *nix anyway.

> VS debugger can do none of the things I look to a debugger to do.

Such as? I'm genuinely curious here. I know of a bunch of things that VS can't do on Windows that requires resorting to windbg (which is a terrible experience compared to VS's debugger), but what are the things you look for in a debugger that it can't do at all? Are we talking user land debugging or kernel?

I use gdbserver to attach gdb to a process on the target machine, running gdb on my dev box where the sources are. In a previous life, I would use a similar capability to debug code in an embedded target through a serial port, with a tiny stub in the target program to manipulate target memory and execution. Nowadays you do that through a USB port.

When I set a breakpoint, I can make it conditional on an expression run against program data, and have it run a series of debugger commands at each stop, and then maybe continue.

Scrolling back through the transcript to see how values have changed at each stop, and running expressions on e.g. differences between such values.

All simple things.

You can definitely do most if not all of that with WinDBG (which is distinct from the Visual Studio builtin debugger). The problem is there doesn't seem to be as much resources around learning how to use it. There are a ton of old hats at MS who know how to perform all sorts of wizardry with WinDBG.

sometimes gdb is what you got. cant always have visual studio when debugging something in a server.

Reply on news.ycombinator.com