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)
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.
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.
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.
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...
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.
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.
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
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.
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.
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.
- 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 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).
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?
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.
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.
/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
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.
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).
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.
