I used to think GDB was a tool with the most broken interface I've ever seen, and which requires arcane commands to do the most trivial of debugging things.

I still do, but I used to too.

That early dig against Windows was particularly funny. There's no way I would pick that over Visual Studio's debugging tools.

userbinator

I agree that gdb's syntax is ridiculous, having come from a background of DOS DEBUG and WinDbg, but what irritates me more are the implementations of certain functionality:

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

- "disassemble" command is next to useless.

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

- 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 don't use gdb often, but when I do, it's usually the option of last resort.

bennofs

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.