Seer – a GUI front end to GDB for Linux | Hacker News Reader

Seer – a GUI front end to GDB for Linux

github.com

209 pointsgjvc60 comments

Will try that one but so far I could not find better than gdb's tui mode. What's good about it if you're a command line vimmer is that it benefits from readline's vi editing mode if you say so in your .inputrc (although it's not as good as zsh's) So jk go up and down your history and other editing goodies. The only crucial piece of information to use it if you are debugging a program that prints stuff to the screen is the refresh command/Ctrl + L to refresh a garbled screen. It also has source code highlighting if you have the right package installed I believe (gnu source highlighting or something)

GDB's TUI had multiple crashes, and gets corrupted too easily.

Ctrl-L to redraw is often required, but that's standard for any tui

Only if the tui doesn’t create pseudoterminals. In 2022, even Windows 10 has them (conpty) and unix has them for like forever (openpty).

Gdb server helps.

Here a quick tutorial from some other HN poster the other day: https://news.ycombinator.com/item?id=33032827

I sometimes run an empty xterm or tmux window and redirect the inferior to it using set inferior-tty

I've given a go at making a GDB GUI (not published anywhere currently). It's at a stage where it looks pretty nice, and is usable for a decent number of basic things, but GDB/MI is such a pain to work with (the existing commands often lack some basic info, some things you may want to query don't have GDB/MI commands, and some outputs are just completely broken (e.g. multiple stop reasons)) that it's sucked pretty much all enthusiasm I had for working on it.

I wish the best of luck to the authors of this; it seems they've already done a majority of the GDB/MI work, albeit largely by substring searches, and likely not handling the tons of edge-cases GDB/MI gives.

Here's a partial list of front ends using GDB https://sourceware.org/gdb/wiki/GDB%20Front%20Ends

One thing that isn't obvious to me is if the "Struct Visualizer" window can let you follow pointers and open other windows to view the struct/class that they reference.

I have used the equivalent feature in DDD a lot.

I really miss DDD! It'd be great if there's a rewrite of it somehow with sane UI/UX. It was great when debugging pointer-heavy code, although I guess this has long gone out of fashion except for niche scenarios like DB indices...

(The Seer author here)

The StructVisualizer can follow *pointers. The default method is to view the struct/class that is pointed at in the same visualizer.

You can RMB click on the pointer in the StructVisualizer to open a second visualizer for that pointer.

I know this is a bit aways from how DDD worked. DDD has a nice way of "graphing" the struct/class tree, including any referenced struct/class that come from pointers.

Who knows, it may be in my plans :^)

A similar project: https://github.com/nakst/gf

How is shilling another project without any remarks or discussion a useful thing to add?

As other comments have noted "at least a few words how it's different ... would be nice."

This is why I like HN. You open a discussion, you see other related projects that may be of your interest. Isn't it neat?

Sure, but at least a few words how it's different from a dozen of other similar projects would be nice.

exactly my point -- replying to a post with a link to another project with no reason why you're doing it just seems to want to detract from the original post

But the submitted link doesn't have that either.

I do not think that turning HN into a bunch of listicles is neat.

Maybe you and I disagree about what is or is not neat. That's okay.

It has some usefulness to people like me. Not that long ago I went through all gdb GUIs I could find to test them , but I found none I liked. Back then I missed the one that is mentioned by the top poster as well as the one linked above.

In general people who click on "a GUI frontend for gdb" might be interested in another front end. However, I have no knowledge, nor I endorse any of them. For what I know they both might be pretty bad, but it is nice to see people are trying to improve gdb's usability.

Having not found a good frontend GUI I eventually learned how to use gdb on its own, with its tui (a kind of console based multi-window "gui") as well as I've used emacs's gdb-mode a lot. Both are huge time savers and they are both really fast. To be fair the only thing that I can't do with them is to explore variables/memory via mouse point and click(one has to use the keyboard a lot) and I find at least for me my mind-mouse-point-and-click connection is a lot more seamless than mind-keyboard-command-type.

Have you tried using cgdb?

I used it to debug an embedded project last as I hated the debugger in VS Code (and VS code itself). It works great with terminus if you want to look at logs while debugging ..

I haven't. Thanks for mentioning it. However, after briefly looking at its website I can't see what functionality other than source code search it has that tui lacks (tui is built into gdb - unless compiled without)?

Tui looks very similar to the screenshot shown on cgdb's webpage. I too use gdb mostly with embedded devices (over swd with openocd). I like to have at least 3 windows with source code, disassembly and memory/variables/watches.

I didn't know about Tui. Thank you to for mentioning it. I have used cgdb since forever.

I would have loved to add more details about the project I linked, but I unfortunately haven't used it a lot. I figured it would be better to just link it in case it's useful to someone, than not link it at all because I don't have a complete description. I don't quite understand your use of "shilling", I have no affiliation to this project.

If you haven't used it then don't be spamming it

In my experience the main problem with the normal gdb UI is the formatting of long templated function names or types.

Funnily enough, no GUI attempts to solve that issue.

The UI certainly looks pleasing. Those with who prefer Qt programs also have KDbg which, as can be inferred from name, is based on KDE libs rather pure Qt and unsurprisingly looks similar to Seer. On the other hand couldn't find a GTK one.

The GNOME ecosystem used to have Nemiver[1], which died because nobody was maintaining it (though there are people working on debugging support in Builder[2]). Of course, there is also DDD[3], the grandfather of all gdb frontends, in pure X11.

[1] https://wiki.gnome.org/Apps/Nemiver

[2] https://builder.readthedocs.io/en/latest/projects/debugging....

[3] https://www.gnu.org/software/ddd/

DDD uses Motif, not just X11.

Can someone explain to me why the visual debugging situation in linux has been so miserable compared to windows?

different audiences, possibly.

*cries in vim*

For devs coming from the full Visual Studio on Windows, VSCode is quite good for debugging with gdb on Linux.

It's mostly that Microsoft and Apple invest a lot of money in their IDEs to attract and retain development talent for the platforms that support the core of their business.

- In CLIs the function (what the software does) is more important than the presentation, in GUIs the usability expectations are higher.

- GUIs need constant cosmetic updates over the years to keep up with design fads

- GUIs in general require more work and a good eye to be considered useful

Linux market dynamics does not have such a "generous" vendor that might recoup their IDE development costs by selling other stuff.

- Historically, the Linux user base has been smaller

- GUIs are seen with contempt by a small but influent portion of the Linux crowd

- Linux users are less willing to pay for software because so much is available for free

Linux and Unix now have radare2/ired/rr, but DDD and gdb can work pretty well too. Also, as everything it's libre/open source, you can set up debugging flags everywhere.

I have the same question. I'm mostly a printf debugger but for some problems cracking out an interactive debugger is invaluable but I've struggled to find one that worked well for me on Linux. I usually end up using command line gdb and it's TUI but I'm not thrilled with the experience. Compared to something like browser debuggers for JavaScript it is so difficult to do simple things (even if the advanced features are more powerful).

- Visual studio has a trillion dollar corporation behind it

- XCode has a trillion dollar corporation behind it

- The graphical debugger projects on Linux pretty much only have volunteers (occasionally) working on them, and none has picked up enough traction to build a significant following and justify any kind of real investment

Also, it has never really been a pressing issue since GDB, LLDB, and tools like RR are perfectly usable from the command line once you learn them.

I imagine the vast majority of people who use debuggers for Linux programs are doing it over ssh.

qtcreator seems to be ok for me - if your project has a CMakeLists file, just do “sudo apt install qtcreator”, “qtrceater .” Then “F5” and you’re off.

Am I missing out on important functionality?

I was looking a bit in gdb frontende recently but still think it would be cool to have a chrome debug protocol adapter for gdb. Or is there something like this?

Or a decent quality vim/nvim interface to GDB.

Yeah there's gdbserver which allows you to connect to GDB over TCP and run commands. You can use the GDB/MI command syntax which gives machine readable output.

Then Microsoft provides an adapter to convert GDB/MI to their standard Debug Adapter Protocol. I think their adapter is unfortunately closed source but there appears to be a third party open source one too.

>there appears to be a third party open source one too

Where?

Here: https://github.com/Marus/cortex-debug/blob/master/src/gdb.ts...

Though I'm not 100% sure it is using the DAP.

Something like gdbgui? Though it’s browser based, not limited to Chrome.

https://www.gdbgui.com/

I'm not familiar with chrome debug protocol adaptor, I kind of assume it is not the same thing as https://microsoft.github.io/debug-adapter-protocol/

In the case that it is, I noticed that tromey had posted some patches for an initial implementation of MS-DAP to the gdb-patches list not too long ago.

https://sourceware.org/pipermail/gdb-patches/2022-September/...

Did anyone manage to compile this?

I get tons of compilation errors.

    /home/user/seer/src/SeerGdbConfigPage.cpp:15:78: error: ‘idClicked’ is not a member of ‘QButtonGroup’
       15 |     QObject::connect(styleButtonGroup,     QOverload<int>::of(&QButtonGroup::idClicked),           this, &SeerGdbConfigPage::handleDprintfButtonGroup);
      |                                                                              ^~~~~~~~~
    make[3]: *** [CMakeFiles/seergdb.dir/build.make:323: CMakeFiles/seergdb.dir/SeerGdbConfigPage.cpp.o] Error 1

(The Seer author here)

Can you provide the version of QT you're using? I suspect it is old. Seer needs QT 5.15.2 or newer.

% qmake --version

% qmake-qt5 --version

Not sure HN is the best forum for debugging such issues, but nevertheless, here goes:

    # lsb_release -a
    Ubuntu 20.04.5 LTS

    # qmake --version
    QMake version 3.1
    Using Qt version 5.12.8 in /usr/lib/x86_64-linux-gnu

    # qmake-qt5 --version
    qmake-qt5: command not found

    # apt-file search qmake-qt5
    qt5-qmake-bin: /usr/share/man/man1/qmake-qt5.1.gz

    # /usr/lib/qt5/bin/qmake --version
    QMake version 3.1
    Using Qt version 5.12.8 in /usr/lib/x86_64-linux-gnu

I don't recall doing anything special to install Qt on my box, likely something along the lines of:

    # apt-get install qt5-default

So in all likelihood, I have the standard Qt5 that comes with Ubuntu 20.04.5, still a somewhat popular and widely used Ubuntu version.

Hope this helps.

>> Not sure HN is the best forum for debugging such issues

You can move the discussion to the github page. :^)

In other news, I tried compiling it on a server that runs a recent version of Ubuntu (22.04) and it does compile and seem to compile and link against Qt 5.15.3

Standard and traditional Qt type headaches, where between many different major versions and deprecated stuff and newly introduced APIs between minor versions, compiling and linking software that relies on Qt is a complete crapshoot.

Also, since you don't provide statically linked binary releases or a flatpak or an appimage, you might want to consider making the source dependencies of your software explicit in the Readme (like e.g. the minimum version of Qt5 required, or the qt5Charts dev libs, definitely not something everyone has installed on their computer).

Anyone else map their media keys to their debugger?

In what sense?

You ever try to pause or resume execution? Maybe want to fast forward through a function or step out and go to the next one?

Just look at the keys they're right there, conveniently ergonomically placed

I've been doing it for years. It works great

That’s what I figured. Ya I grew up with the F keys being used for debugging, and that’s a big reason I actually just never have media keys enabled lol.

Yeah me too. They problem is we get locked into modalities that were common when we started using computers.

People use vim say, because the computer when they were 15 didn't run emacs well and now they're 45 and because of this fairly unrelated fact from 1992 they're still doing the same thing.

I try hard to question these assumptions and move on. I use USB foot pedals as quasi-mode keys and sliders and knobs of MIDI controllers to do things like go through browser tabs, window stacks, file hierarchies, scroll through files...

Just my style.

I've thought about trying voice dictation or using the 6DOF sensors on an old phone maybe for a ZUI interface (say figma) but I haven't explored it yet.

Pulling this off in X requires a lot of esoterica of virtual keyboards and named pipes but it's totally doable. We need to find better ways to interface computers and I'm convinced that will not come by attaching a smartphone to our face (or by groups like MIT media lab either. I've worked with them and I wish it were otherwise).

Also I've been learning emacs, it's actually pretty neat.

Brings me back to using xxgdb to debug the first Linux C programs I wrote.

Where do you type in the gdb commands?

Would this work with Rust?

yes

The example screenshot shows Fortran. I would imagine Rust to do better than that ;)

Couldn't give this a try: I'm on Mac and don't have any access to Linux system at the moment.

GDB itself officially supports Rust, with some gotchas: https://sourceware.org/gdb/onlinedocs/gdb/Rust.html

So, in theory it should work :D

Reply on news.ycombinator.com