Debugging with GDB

#1

Post by ingve » Sat, Mar 19, 2022, 8:54 PM UTC

Re: Debugging with GDB

#2

Post by ho_schi » Mon, Mar 21, 2022, 1:51 PM UTC

Took me some time to get familiar with it but GDB is well documented and fulfills its duty. It looks ancient but it is powerful.

Do not underestimate the power of the print command! And the advanced stuff like revers-debugging, multi-threading (all-stop mode - which is the default - and the non-stop mode), binary manipulation (yep, it is possible), and remote debugging. Nowadays accompanied by stuff like debuginfod. What still need to try is the TUI modes because I assume it will improve my personal experience once I find a way of using it.

I've ended up writing all stuff useful for me onto paper, later a markdown and I can recommend everyone doing similar. GDB's learning curve is not like VIM (which is either a wall or a rocket - both looking similar on paper) but it is going upwards.

Today's highlight is "Why do I've to set up all my breakpoints again? You need to save them like an IDE":

https://sourceware.org/gdb/onlinedocs/gdb/Save-Breakpoints.h...

Re: Debugging with GDB

#3

Post by dijit » Mon, Mar 21, 2022, 2:01 PM UTC

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

Re: Debugging with GDB

#4

Post by buserror » Mon, Mar 21, 2022, 2:35 PM UTC

One absolutely essential companion to gdb is 'rr' [0], it's a 'post mortem' debugger, but unlike a core file, you can replay the action, in reverse if necessary. You can reverse-cont, reverse-step create watchpoints, run forward again etc etc. It's absolutely amazing!

[0]: https://rr-project.org/

Re: Debugging with GDB

#5

Post by synergy20 » Mon, Mar 21, 2022, 3:07 PM UTC

dijit wrote: post #3

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 closes…

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

Re: Debugging with GDB

#6

Post by bee_rider » Mon, Mar 21, 2022, 3:12 PM UTC

I generally stick pretty close to the classic "old but still good" tools, but GDB is something I really could not get a handle on (probably because it isn't a daily-use tool for me).

Re: Debugging with GDB

#7

Post by dotancohen » Mon, Mar 21, 2022, 3:20 PM UTC

ho_schi wrote: post #2

Took me some time to get familiar with it but GDB is well documented and fulfills its duty. It looks ancient but it is powerful. Do not underestimate the power of the print command! And the advanced stuff like revers-debugging, multi-threading (all-stop mode - which is the default - and the non-stop mode), binary manipulation (yep, it is possible), and remote debugging. Nowadays accompanied by stuff like debuginfod.…

  > I've ended up writing all stuff useful for me onto paper, later a markdown

Would you like to share? :)

Re: Debugging with GDB

#8

Post by jokoon » Mon, Mar 21, 2022, 3:20 PM UTC

How difficult is it to setup an editor like sublime text with gdb?

I'm curious if it can be an alternative to visual studio, meaning a window showing the stack, locals, watch, etc?

Re: Debugging with GDB

#9

Post by doix » Mon, Mar 21, 2022, 3:23 PM UTC

dijit wrote: post #3

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 closes…

In a past life I used Voltron[0] with lldb. Depending on your use case, it might be enough? Watching what value lives in what register works at least (or at least worked last time I used it). It's designed around having things in separate terminals, so you'll need tmux/screen/tiling window manager to get a similar view to gef.

[0] https://github.com/snare/voltron

Re: Debugging with GDB

#10

Post by Decabytes » Mon, Mar 21, 2022, 3:30 PM UTC

I learned a lot of debugging using GDB from Greg Laws CPPCon talk https://www.youtube.com/watch?v=-n9Fkq1e6sg. With that being said, one of the things I've heard is that debugging on Linux is a poorer experience than it is on Windows. I believe that RAD Game Tools tried to create a debugger for Linux that was better, but the project failed for some reason. I hope with the increased interest in Linux, GDB or another debugger can be improved enough to address the issues people have historically had with it