3 ms·

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://gi

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/cyrus-and/gdb-dashboard, https://github.com/hugsy/gef https://github.com/hugsy/gef, https://github.com/pwndbg/pwndbg https://github.com/pwndbg/pwndbg, https://github.com/longld/peda 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.

saaadhu 9y ago
"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.
- bennofs 9y ago
  Oh! That makes sense, thank you. It only raises the question though, does anyone really use hexadecimal line numbers? :)
  - ithkuil 9y ago
    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
btschaegg 9y ago
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.

saaadhu 9y ago

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

bennofs 9y ago
Oh! That makes sense, thank you. It only raises the question though, does anyone really use hexadecimal line numbers? :)
- ithkuil 9y ago
  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

btschaegg 9y ago

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.