First of all, I agree! GDB without extensions is not that nice to use. But there exist several extensions (https://github.com/cyrus-and/gdb-dashboard, https://github.com/hugsy/gef, https://github.com/pwndbg/pwndbg, https://github.com/longld/peda, even though developed for it, these are not only useful for exploit dev!) that make it a lot better.

> - No way to get a 16-column (bytes+ASCII) standard hexdump. This is functionality that even the most basic debugger should have, yet it's missing from gdb.

This should be quite easy to implement as a small python snippet that you put in your ~/.gdbinit. Granted, this should be builtin functionality, but it also shows how extensible GDB can be.

> - If you write "b 0x12345" intending to set a breakpoint at address 0x12345, it doesn't work. An unnecessary and nonsensical extra asterisk is needed (which makes it look like it's retrieving 4/8 bytes from 0x12345, and using that as the address of the breakpoint.)

Agreed, I never understood why that was necessary. It is really annoying. Perhaps someone wanted to avoid a conflict if you had a symbol named "0x12345"? (can you even do that?)

> - Starting gdb with a binary and passing arguments to it --- you'd expect it to be smart enough to realise that anything after the executable name should be the arguments to the debuggee and not the debugger, but it isnt.

I recently learned that gdb has a neat option called --args, that does exactly this:

    gdb --args program arg1 arg2

GDB feels quite similar to VIM to me: you have to spent some time to get used to it, it has some warts but it is very flexible and useful if you know it.

"b 0x12345" will place a line breakpoint at line number 0x12345 of the current source file. The "nonsensical" extra asterisk is used to tell gdb that you want an address breakpoint instead.

Oh! That makes sense, thank you. It only raises the question though, does anyone really use hexadecimal line numbers? :)

Just a guess: if you have an expression language that lexes numbers in a few bases, then when parsing some commands you no longer know which base the number token was, all you know is that you got a number, and in case of the break command you interpret that as a line number unless prefixed with a * token

That's about the same vibe I got from GDB so far. I don't use it all to often, so I'm certainly not that "effective" in it, but I still get my debugging done. And yes, it is a bit arcane.

However, on the topic of picking this over the VS debugger: The lack of arcane configuration, socket permissions and usage steps required to get it running on remote machines is what would make me pick it over VS nearly all the time. I haven't yet gotten to try the VS2017 one, but its predecessors were abysmal in that regard.

Tellingly, GDB's simplicity in that regard - which is the same as far as many other UNIXy tools go - comes from the approach of "if you have an SSH connection, you're good to go", which is something that is lacking in almost any Microsoft tool.

GDB is used in lots of places, often times called programmatically. You can't just change long-standing behaviour and get away with it. This is not a web framework.

So additional positional arguments on the gdb command line will always be interpreted as core files or PIDs instead of being passed through to the inferior program (unless using --args).

Similar things apply to other complaints.

You don't explain how "disassemble" is useless, but the rest of the things you mention are extremely superficial.