> I am kind of lost when trying to debug a binary on windows

When I want to debug a program using the Visual Studio IDE I do the following:

1. Start the IDE and open the solution file.

2. Make sure the Debug Build option is selected.

3. Open a given file in the solution that I want to debug.

4. Select a line in that file and use the Debug, Toggle Breakpoint menu to set a breakpoint.

5. Run the debugger using the Debug, Start Debugging menu and wait for the breakpoint to be hit.

6. When that break point is hit just use the debugger to examine the state of the program.

While a simple series of steps it's still pretty complex compares to the equivalent in gdb:

  $ gdb ./binary
  (gdb) break file.c:line
  (gdb) run

I think this is merely a disguised version of the "CLIs are too hard" argument...

Calling it "CLIs are hard" is trivializing it but anyway, it depends on what your common case is. For C/C++, CLIs slow me down tremendously. In an IDE, You don't need to type a single command to view program state (automatic + local + thread storage), call stacks, memory usage, CPU Usage, Heap activity, unpacked C++ containers, GPU state, etc. But this is not even that impressive TBH. FME Windows in general is better at debug symbol management than Linux especially when it comes to shipped binaries. The post[0] sums it up nicely:

"I can take a crash dump file from a customer running an arbitrary version of our games, running on an arbitrary version of Windows, load it into the debugger and have all of the symbols automatically show up. I don’t need to know or care what version of the game or what service pack of Windows the customer was running, and I don’t need to think about package names or new repositories. The symbols and binaries Just. Show. Up."

[0]https://randomascii.wordpress.com/2013/02/20/symbols-on-linu...

The symbol thing sounds useful and is something I cannot comment on, since most often I either debug open source programs that I run myself (so I have the binary with compiled with debug symbols) or there is no source at all for the binary (and so no symbols). But, most of the other things you listed are, IMO, quite easy with GDB:

> view program state

in my experience, your often only interested in a few variables. then, you just run

    display var

once for each variable and GDB will show the value of var on every break. There is also `info locals` to show a local variables, and I am pretty sure that you can set it up to run on every break with some simple config (there's probably an extension pack that does it)

> call stacks

almost every enhancement plugin for GDB in python that I know of does this (GEF, voltron, ...)

> unpacked C++ containers

I am pretty sure GDB pretty-prints C++ containers?

This isn't to defend GDB, it cannot do Heap activity or CPU usage or GPU state out of the box and sometimes, a visual interface is nicer. I just wanted to comment on what is possible with GDB, because I was often not aware of that either.

>This isn't to defend GDB, it cannot do Heap activity or CPU usage or GPU state out of the box and sometimes, a visual interface is nicer. I just wanted to comment on what is possible with GDB, because I was often not aware of that either.

Surely then, the difference between whats possible, and whats easy/default out of the box isn't simply "CLIs are hard" ! :)

Anyway it seems like we'd agree on most things, so nothing really left to discuss.

However, it is a lot more intuitive compared to gdb: Click the green arrow. Click the line you want to set a breakpoint on. See where you stopped in the same editor that you wrote the code in. Hover your mouse over variables to see their values, visually explore class and array variables. Dig down into functions that are about to be called, before you actually call them.

> While a simple series of steps it's still pretty complex compares to the equivalent in gdb:

Oh come on. If you're developing with visual studio, you've already got it open and have been compiling with it.

Debugging in VS is literally click the mouse where you want to stop, F5, full call stack/local variables there in front of you.

Given the list above, if you reproduce a similar list for gdb it is also pretty tedious: run a terminal emulator, spawn a new shell, cd to the directory you want to work in, compile the program with gcc with the appropriate flags, run gdb with the appropriate arguments.

Visual Studio has a command window that you can use if you want to type commands rather than use the GUI. Plus, the person you replied to was being very descriptive. Just as you start gdb and pass the binary name as a parameter, you can do the same in Windows by double clicking on the solution file.

Now try complex logic, only break here if this this and that happened just before. GDB can be much better for that.

Where VS shines for me is inspecting the state of datastructures. As long as you don't need to do any complex search on them, or programmatically walk a graph of them.

> a binary

I'm not sure that there's a VS project and source code available for the binaries in question.

Well if there isn't, you can start the EXE and do Debug|Attach from VS. Or (I think?), you can go to File|Open Solution, open the EXE directly, and let VS create a temporary solution for you that will let you run the EXE as a debuggee by pressing F5.

If you're debugging an EXE without source because you're writing a plugin or addon for it as a DLL, and you want todebug that DLL, you can specify the EXE in question as the EXE to run when you start debugging as part of the properties for the project for the DL in question. Visual Studio will spot when your DLL loads, load the debug info for it, and activate any breakpoints and so on. Works well.

(If your addon runs as a child process, you need the Child Process Debugging tool. Transformative. Get it here: https://marketplace.visualstudio.com/items?itemName=GreggMis...)

When you don't have source code, VS is not the best environment ever - it's oriented very much towards worknig with C/C++/etc., and there's a few options you have to play with to get it to show you disassembly and so on. But it's adequate. (One thing I like about it very much is that the step commands are the same whether you're stepping through source code or whether you're stepping in the disassembly window. I'll put up with quite a lot in exchange for that.)

In Visual Studio 2017 you can open an executable directly and begin debugging it without having either of those things.

So... just like every IDE that integrates GDB then ?

Exactly. gdb is just like gcc. I can see the point of having a command line version of a compiler for toying and for automation/build scripts etc, but I rarely see the need to type out compiler commands. Same with a debugger.

Debugging a binary that you don't have source to, and that you don't intend to modify the reduces the benefit of the full IDE (where your syntax view in debugging is the same as your editor). Still, you get all the niceties of the IDE. You break on a line, step further on some lines. Notice the bug happen after y = foo() + bar(). So you wonder "where are those?" and you F12 with the cursor on the method name to nav to that method once there you set a breakpoint on the first line, and run so you debug that next.

Also, if you add in edit-and-continue so you can modify the code and have it automatically recompiled and keep debugging it, that adds value too.

I assume that various editor adaptations for vim/emacs etc means that you get almost all the IDE experience with gdb as well (symbol navigation, syntax highlight etc) and at that point there is of course little difference between one IDE and another.