What does HackerNews think of pwndbg?

Emulating an emulator inside itself. Meet Blink | Jan 2023

You can go other way around and use other TUIs for GDB:

* https://github.com/pwndbg/pwndbg * https://github.com/longld/peda * https://github.com/hugsy/gef

Hacked GDB Dashboard Puts It All on Display | Mar 2022

There are a lot of these types of tools already in the reverse engineering community (in order of lowest chance of breaking when you throw really weird stuff at it, in my experience):

GEF: https://gef.readthedocs.io/en/master/

PWNDBG: https://github.com/pwndbg/pwndbg

PEDA: https://github.com/longld/peda

They also come with a slew of different features to aid in RE/exploit dev, but many of them are also useful for debugging really weird issues.

Also if you don't need all the info these provide or just want to augment them, the tool you are looking for is "hook-stop" which allows you to execute a string of commands every time GDB pauses program execution.

Debugging with GDB | Mar 2022

Expand Context ↕

I'll also plug pwndbg[1] here. Like Gef it greatly extends the utility of GDB, and is oriented around exploit development.

[1] https://github.com/pwndbg/pwndbg

Debugging with GDB | Mar 2022

GDB is great. I definitely recommend checking out watchpoints as well, a very useful tool for monitoring how a variable changes over time.

GDB also has many good plugins - pwndbg has tons of features and UI improvements over stock GDB.

https://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.ht...

https://github.com/pwndbg/pwndbg

The State of Linux Debuggers | Dec 2020

I think you would love pwndbg

https://github.com/pwndbg/pwndbg

Ask HN: Which tools made you a much better programmer? | Jun 2020

* `perf top`

* `scan-build`

* https://github.com/pwndbg/pwndbg, a very comprehensive gdb extension/config.

Give me 15 minutes and I'll change your view of GDB (2015) [video] | Aug 2017

Expand Context ↕

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.