HN Reader

I built it and tried it out a bit with Godot on Linux. It seems OK (the UI is a bit on the "- how many widgets do you want? - yes" side), but also a bit janky. Trying to change the font for the editor didn't work, hovering over a variable to see its value either does nothing (but there is a sub-second cursor change that indicates something is supposed to happen) or it shows an error from GDB about trying to use an expression with a type or keyword (so there was an intent to show a value on a tooltip, it is just broken) - doubleclicking on a variable does add it in some panel with its current value and a timestamp, so the functionality for reading values/expressions from the UI is there too, just not done in the same way as the tooltips.

If polished a bit it could be useful, though from all the frontends i've tried the one i disliked the least (none are great) is Gede[0] (which i just noticed had a new release a few hours ago) as it has a very simple and straightforward UI and while it doesn't expose much functionality, what exposes seem to work fine without bugs.

[0] https://gede.dexar.se/

GDB also has a built-in text user interface (TUI) that is surprisingly easy to use[1]. It even supports mouse interaction.

[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/TUI.h...

After trying many frontends for gdb I find that the TUI is the best. You just need to know about Ctrl + L to redraw if your program is printing stuff because the interface then become garbled.

I just put :

   layout src
   set confirm off

in my $XDG_CONFIG_HOME/gdb/gdbinit

In case you are in Windows, and connected to Linux and/or using WSL, you can also use WinDBG/VisualStudio to debug (remotely) Linux processes!

This is a Qt UI for GDB.

There's also gdbgui that I know of, a web-based UI for GDB:

https://www.gdbgui.com/

Always good to see more movement in the debug tooling

This combo works well for me: neovim + nvim-dap + nvim-dap-ui + gdb (with native DAP protocol support).

On a general note, I would recommend any new (and experienced!) programmers to master the debugging tools of their ecosystem. I've seen countless experienced developers use printf-based debugging and waste hourse debugging something which could've been easily figured out by setting a breakpoint and stepping through your code. This is also a good way to understand code you're unfamiliar with.

This is one area where I believe a GUI tool is so much better: I can hover over variable names to view their values, expand and collapse parts of a nested structure, edit values easily, and follow execution in the same environment I write my code in.

Sure, it doesn't help much for some scenarios (one I've heard people mention is multithreaded code, where logs are better?), but for most people it's not that far from a superpower.

Qt GUI itself can use gdb/ldb and display a fair amount of data structures from the standard library.

Note that gdb is also scriptable with python, so you can easily register your own printers.

pwndbg, gef, edb

oh nice - reminds me of DDD(1) DDD was like magic first time I saw it. Oh wow - DDD is still maintained ?? :-D

1 https://en.wikipedia.org/wiki/Data_Display_Debugger

2 https://www.gnu.org/software/ddd/

Anyone has experience with this and can compare it to kdbg?

The GNU project (and RMS) seem to get a lot of meme-ridicule, but GDB is a powerhouse. I've only had occasion to mess with it a little, but it seems to have had such a huge impact on people's development work over the years.

A mediumish discussion 2 years ago https://news.ycombinator.com/item?id=33044885

For the Emacs users in the crowd, GUD is a pretty great GDB integration.

Is this using vscode's DAP under the hood?

I sometimes need to use gdb to investigate bugs in C or Ada, but it is not my main activity. As a result I will not invest days to setup a debugging environment that I will not remember how to use 6 month later. My solution: I use emacs and have a short note with instructions: M-x gdb -i=mi exe_full_name -p 29123 M-x gdb-many-windows set follow-fork-mode child

When I used to program in C++ on Linux 10+ years ago, I used Qt Creator which has a built-in debugger (GDB frontend). It worked great and I don't see a reason to use anything else for C++ [and Qt].

eclipse-cdt includes a GDB integrated debugger UI for C and C++ since forever. What's new here?

Debugger vs printf:

Has anyone found a reliable way to use a debugger when you have a) multi-process b) multi-threaded c) async d) timeouts? I would love to use a debugger but printf and logs “just work”

See also https://github.com/nakst/gf

Long time gdb TUI user, migrated to VSCode recently. Haven't looked back. Occasionally I do use TUI to look at the disassembly.

Slightly off topic but I think it is a good place to ask: One of the few things from windows that I miss when using linux is the debugging experience with visual studio (not code). When debugging a medium-sized C++ project on windows, the launch of the debug build is pretty fast and stepping over lines is almost instantaneous. On linux launching the executable using gdb takes like 10 seconds loading modules and stepping over each line takes like half a second which I think is intolerable (lldb is even worse). Yet I don't see people complaining about this online very much. Am I missing something? E.g. is there a compiler flag that speeds up debug launch time and step speed that I am not using?