gef VS gdb-dashboard

There is also GEF, which is widely used by the reverse engineering and CTF community.

https://github.com/hugsy/gef

https://github.com/hugsy/gef, https://hugsy.github.io/gef/, https://hugsy.github.io/gef/commands/context/ ("Values in red indicate that this register has had its value changed since the last time execution stopped.")

The attached debugger is not just raw GDB but is using https://hugsy.github.io/gef/ to make debugging less of a pain. It's still not perfect but helps plenty already.

I still struggle with GDB but my excuse is that I seldom use it.

When I was studying reverse engineering though, I came across a really cool kit (which I've yet to find an alternative for lldb, which would be nice given: rust)

I'd recommend checking it out, if for no other reason than it makes a lot of things really obvious (like watching what value lives in which register).

https://github.com/hugsy/gef

LLDB's closest alternative to this is called Venom, but it's not the same at all. https://github.com/ovh/venom

Using vanilla GDB is painful. As a bit of a shameless plug I recommend you check out GEF[1]. It's a large python script that extends GDB to make it a lot better to use. Notably it shows a lot of the state automatically every time the inferior stops. It's oriented around reversing and exploit development, but it definitely doesn't have to be used that way.

[1] https://github.com/hugsy/gef

GEF - GDB plugin.

The problem with console gdb is that its default settings suck. I have this config, first line switches 64/32 bit mode. Yours is 32. File goes to ~/.gdbinit. I won't claim to have best config ever, google for it if you want to. There's also https://github.com/hugsy/gef

To debug, termdebug is built in to vim and supports a front end to gdb. In combination with gdb-dashboard this gives a reasonably good debugging experience

https://github.com/cyrus-and/gdb-dashboard, https://github.com/cyrus-and/gdb-dashboard/wiki

I was using gdb-dashboard: https://github.com/cyrus-and/gdb-dashboard seems kind of like gef.

Try GDB Dashboard, it makes gdb much easier to use:

https://github.com/cyrus-and/gdb-dashboard

There's also Voltron which works with both gdb and lldb (amongst others):

https://github.com/snare/voltron

I can't believe no one has mentioned `gdb-dashboard` [1] yet! I use it extensively. [2]

Beyond that, I have recently learned how to write custom pretty printers for GDB. This saves a lot of screen space. I should probably update [2] soon with those new techniques.

GDB is powerful, useful, and after getting my start in IDE debuggers, including Visual Studio, I struggle whenever I have to go back.

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

[2]: https://gavinhoward.com/2020/12/my-development-environment-a...

Debugging: Learn gdb. You can use it for assembly. You can use it for C on a MCU. You can use it for Go on a Linux system. It’s ubiquitous, versatile, and worth understanding. You can pretty-print the output with something like this to help you out at first. There are 2 things you need, however: on chip debugger and a debug probe (though you don’t need an expensive one). Effectively, you talk to GDB, GDB talks to the server exposed by OCD, OCD knows the debug probe protocol, and the debug probe can use the MCU debug peripheral via SWD or JTAG to get those details.

gdb-dashboard: https://github.com/cyrus-and/gdb-dashboard Just a pretty wrapper for gdb, so it’s as stable as gdb itself. Pretty good if you like to stay in the terminal. You can run python scripts from it since you’re actually in gdb

I would even suggest use of System View Description – I use gdb-dashboard + gdb-dashboard-svdregisters. There are alternatives, of course.

There are a couple of wrappers that try to enhance it like GDB dashboard and GEF.