
Give me 15 minutes and I'll change your view of GDB (2015) [video] - pmoriarty
https://www.youtube.com/watch?v=PorfLSr3DDI
======
yen223
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/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
"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
Oh! That makes sense, thank you. It only raises the question though, does
anyone really use hexadecimal line numbers? :)

~~~
ithkuil
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

------
grassfedcode
Just wanted to mention gdbgui, a new front end to gdb that I developed which
is similar to Chrome's debugger, has a gdb terminal which you can fall back to
if you want to run gdb commands, and data structure/value plotting and
visualizations similar to ddd.

[https://github.com/cs01/gdbgui](https://github.com/cs01/gdbgui)

~~~
cheez
This looks great! Did you know that you can also use Chrome's debugger to
debug Node? I wonder how difficult it would be to use Chrome's debugger as a
front end for gdb.

~~~
grassfedcode
Never tried, but pygdbmi would probably get you halfway there. It uses python
to parse structured data (key/value pairs) from gdb output. Gdbgui uses it on
its backend. (Disclaimer: I am the developer)

[https://github.com/cs01/pygdbmi](https://github.com/cs01/pygdbmi)

Also for golang: [https://github.com/cyrus-and/gdb](https://github.com/cyrus-
and/gdb)

------
kerneldeveloper
If you want to use a powerful gdb visual interface, you may want to try DDD.
However, DDD has an old-fashioned GUI which is very crude. I have tried
several visual debugging tools, such as RedHat Insight, DDD, Nemiver and kdbg,
but none of them is enough powerful or stable. As far as I know, DDD can't
display non-English comments in source code.

Now I'm using an awesome GDB init file to construct a convenient debugging
interface. It's an open source project and you won't regret it:
[https://github.com/cyrus-and/gdb-dashboard](https://github.com/cyrus-and/gdb-
dashboard)

There is also a browser-based frontend for GDB:
[https://github.com/cs01/gdbgui](https://github.com/cs01/gdbgui)

If you want to try more, search the keyword GDB on GitHub and sort by stars,
then you will find many GDB enhancement tools.

~~~
nocman
Qt Creator is also a fairly decent front-end to gdb (
[http://doc.qt.io/qtcreator/index.html](http://doc.qt.io/qtcreator/index.html)
).

------
okket
Previous discussion from a year ago:
[https://news.ycombinator.com/item?id=12101347](https://news.ycombinator.com/item?id=12101347)
(169 comments)

------
jdright
Some other very nice:

[https://github.com/snare/voltron](https://github.com/snare/voltron)

[https://github.com/cyrus-and/gdb-dashboard](https://github.com/cyrus-and/gdb-
dashboard)

I particularly like Voltro's view modularity and backends support. But
dashboard is a really nice throwback (SoftICE) with its theme and sensible
default layout.

~~~
Graziano_M
GEF as well: [https://github.com/hugsy/gef](https://github.com/hugsy/gef)

Voltron adds awesome views, GEF adds a lot of handy functionality. I use both
(often together)

------
iopuy
If you want a powerful debugger with a crappy interface that is widespread
(and programming java) try jdb. It comes with the freaking jdk tool chain so
it is basically everywhere, however, gdb can't hold a candle to the horrible
experience it is to use jdb without a graphical frontend. The documentation is
about a page and a half, that is all, classes must be fully qualified with
packages (which can have dozens of levels) in all commands, and it does not
use readline for input!!! No left or right arrow to move the cursor! /rant

------
zython
The TUI in gdb is a great way to get started with gdb. Instead of writing your
own hooks and commands you can visually step through the program and source
code ( if you have debug symbols enabled)

I think that more people should know about this feature.

~~~
frankzinger
Absolutely. Many of the comments here deride the default gdb interface but the
TUI is orders of magnitude more usable and I only learned of it recently. (I
much prefer it over Emacs' interface, for example, something another commenter
recommended.) And in single-key mode it's even better.

------
bennofs
I found rr to be much better for reverse debugging than gdb's record feature.
For some reason, hardware watchpoints while reverse-continuing don't work for
me when using gdb record but do when using rr.

~~~
elsjaako
He mentions this in his longer talk:

[https://www.youtube.com/watch?v=-n9Fkq1e6sg](https://www.youtube.com/watch?v=-n9Fkq1e6sg)

------
throwaway2016a
There are only three comments so far so small sample size but am I the only
one who actually likes working in GDB?

Then again, I also use Vim as an IDE. But so do a lot of folks here.

------
mtve
for those who are still prefer documents over video, pdf slides are at
[https://github.com/CppCon/CppCon2016/tree/master/Tutorials/G...](https://github.com/CppCon/CppCon2016/tree/master/Tutorials/GDB%20-%20a%20lot%20more%20than%20you%20realized)

------
xvilka
radare2 recently added reversible debugging feature too:
[https://radare.gitbooks.io/radare2book/content/debugger/revd...](https://radare.gitbooks.io/radare2book/content/debugger/revdebug.html)

Note, that you will need version from git, but anyway, new release of radare2
will be ready in less than a couple weeks.

------
0xcde4c3db
The "flipping back and forth" that he seems so impressed with, combined with
the arcane key bindings (I know they're Emacs-inspired, but that's little help
when the navigation model doesn't actually work like Emacs windows/buffers),
is why I dropped TUI pretty quickly. Besides, I have 3 1080p monitors; a UI
designed for a VT220 is not the best use of that setup.

It also doesn't help that I've never gotten gdbserver to actually work
reliably on my embedded Linux targets (which, to be fair, are not
Cortex-A/Apple/Qualcomm chips, so probably being tested by ~nobody). I'd
understand if some operations aren't supported due to missing debug hardware
or emulation magic, but stuff tends to just start mysteriously breaking (e.g.
not stopping on breakpoints, hanging when trying to print memory, crashing on
resume/step, etc.).

------
abbeyj
If don't like the Ctrl-X,A shortcut to get into TUI mode there is a command
line option (--tui) to get GDB to start up in TUI mode. I find that a lot
easier to remember.

I think cgdb ([https://cgdb.github.io/](https://cgdb.github.io/)) is even
better than TUI mode though. Some nice things that it has that TUI mode
doesn't:

\- Colorization of the source code window

\- The terminal display doesn't get confused when the debugged program prints
to stdout

\- You can still use the up and down arrow keys for moving through your
command history and don't have to resort to Ctrl-P and Ctrl-N. Scrolling the
source code window also uses the up and down arrow keys but you have to switch
the "focus" to the source code window first.

~~~
Asooka
> \- You can still use the up and down arrow keys for moving through your
> command history and don't have to resort to Ctrl-P and Ctrl-N. Scrolling the
> source code window also uses the up and down arrow keys but you have to
> switch the "focus" to the source code window first.

Minor correction, that's the same as gdb tui. Use ^X,O to select which window
has focus and you can use up and down arrow to go through your command
history. The rest is definitely better in cgdb.

------
vidarh
As I've written on this subject before, I think current debuggers largely miss
the point, though gdb misses the point in a whole different league.

What I want from a debugger is 99% of the time met by gdb by running a program
and running a backtrace and inspecting a few variables. Where gdb falls flat
by default is in making me type in commands to get a register view, backtrace,
disassembly of the current area, and the current stackframe.

Most other debuggers do ok there. But even with gdb it's trivial to define a
few macros to make that part easy.

Where every debugger I've used falls flat is that for most harder problems,
their functionality seems focused on heaping on functionality to let me do the
job the debugger should have, instead of actually doing the things that would
really save me time.

I've increasingly instead turned to valgrind as my first choice, for the
simple reason that a huge portion of the problems I deal with are low level
(e.g. debugging my compiler, which involves debugging things like why my code
generation doesn't correctly initialise a value on the stack. But this is the
same problem I generally would like to be able to debug in higher level
languages:

Program crashes. Which value caused the crash, or caused the exception to be
thrown? When was that value set? Where? What was the code paths that led to
that value being set? Which variables contributed to it being set to that
value?

Fully automating this in the general case is not possible (it devolves to the
halting problem if you don't put the debugged program in a "black box"), but
making it easy for a human to guide it there should be the priority for a
debugger.

Being able to get a quick view, see that "huh, that value shouldn't be there",
be able to tell the debugger "identify when that variable will change and re-
run", and work your way back that way, would solve the vast majority of the
tough debugging sessions I've had.

Note that the above is _not_ the same as just setting watch-points by tracing
and checking. Handling of watches is usually crude in most debuggers. What I'd
like is something similar to Valgrind - to do this well the debugger needs to
at least analyse the code and intelligently pare down what it watches, and
ideally dynamically translate the code into something sufficiently
instrumented to let it run fast. For most debugging sessions where I've tried
watches, I've had to give up because of how slow they can be, but if the issue
is something valgrind can catch, it finds it fast.

Support for replays might be an improvement, but it's still about providing
tools for us to do the debuggers job instead of semi-automating vital
functionality.

~~~
roca
You should try using rr. The combination of reverse execution and hardware
data watchpoints enables new, much more direct, debugging strategies to answer
the kinds of questions you posed.

~~~
vidarh
rr doesn't work on my CPU yet. Or at least not without building from git, and
that fails due to some compilation problem or other. I haven't had time to try
much more than that, but from what I can tell from the docs it does seem
_better_ though I think at unnecessarily high cost. I already have code that
make Valgrind fall over because its state exhausts my memory, so I'l be
interested in seeing how rr fares there.

~~~
roca
File an rr issue if you have trouble getting it working.

------
tbrock
The reverse debugging portion of this video was mind blowing. I had no idea
you could do that.

------
LeoNatan25
WinGDB exists and allows remote debugging in Visual Studio to remote machines
using gdbserver. Used that in my previous job and was very convenient.

------
corndoge
A video targeted towards people who haven't spent fifteen minutes in gdb but
already think it sucks. Cool beans, just what HN needs

------
pankajdoharey
I prefer valgrind over GDB.

------
raarts
[2015]

------
futurix
15 minutes!?! Gosh, even changing my views will be slow with GDB ;-)

~~~
futurix
I'll take a textual article over video any time.

------
ustokes
Agree. I started embedded coding on Linux + Qt-Creator. I have everything
working, compiling and running on my ARM and AVR chips, but Debuging jsut does
nto work. Just can't find any proper info on how to integrate GDB into Qt-
Creator and be able to just Debug like in Visual Studio. If this is not
possible, that this endeed is very stupid, starting/stopping servers on a
remote target and the rest...﻿

~~~
dman
I don't think the situation is likely to improve much unless as a profession
we become open to paying for quality tools.

~~~
pjmlp
We used to be open to paying for quality tools, then the FOSS generation took
over, killing the business of selling tools to single developers.

Nowadays the only way to make money selling developer tools is to sell them to
enterprises, the only ones that value developer time vs money spent on
tooling.

------
Wiegand_dawson
Why not use cgdb?﻿

~~~
doostee
I much prefer the cgdb interface to gdb's tui. I've also used it with various
embedded builds of gdb. It works great.

------
kali46
Ever heard of a not so new tool called IDE? You are welcome.﻿

~~~
xaedes
my whole computer is my integrated development environment =)

