Seer: A GUI front end to GDB for Linux

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...

Only works if GDB has been built with TUI support, sadly :(

… If you are debugging c code surely you’re able to compile a debugger with whatever options you want?

Is it not usually? I've never had to compile gdb myself to get TUI

This has definitely been an issue for me before, I think at least for a while Ubuntu/Debian didn't ship gdb with tui enabled, you had to build it yourself.

Neovim + nvim-dap + nvim-dap-ui + gdb works much nicer than that.

Only seen on some minor embeded systems but it’s not a big deal to compile gdb with tui support enabled.

How have I never heard of this before? Thank you.

In theory, yes, but in practice, people who know how to compile gdb is a small subset of people who need to debug c code.

Not to mention that it actually takes extra time to do so, when people are used to debug Python/JavaScript/Go code with one single click these days.

Personally I prefer cli over tui, but you can just toss something like this in a `.gdbinit`:

  tui new-layout default regs 1 {-horizontal src 1 asm 1} 2 status 0 cmd 1
  tui layout default
  tui enable

Just grabbed the source, and it's a pretty bog standard ./configure ; make. Simple build instructions in the readme. Not sure this is a daunting challenge for any even moderately skilled developer.

Most people who use C nowadays are students, not "moderately skilled developers".

Students barely know how to manually put together a Makefile.

Where? How?

Last time I tried to build GDB from source, which was some two months ago, it wasn't in any way simple. GDB comes embedded in some GNU binutils repo, instructions to build it in isolation weren't obvious.

I ended up creating a new VM with a more recent Linux distro, that came with newer GDB, and migrating everything I'm working on to it, because that was much easier than building GDB from source.

The GDB source is available as a standalone package: https://www.sourceware.org/gdb/download/

As long as the number of programmers is growing rapidly, it’s likely that most people who use any language are probably students. The distribution automatically skews toward beginner.

That has no bearing on whether we should have good tools for skilled developers, including debuggers & makefiles & source distributions. Eventually, students become moderately skilled. And we used gdb in class when I was a student.

> That has no bearing on whether we should have good tools for skilled developers, including debuggers & makefiles & source distributions.

Unfortunately, it's also the best explanation as for why we don't have them in practice, and why all software seems perpetually developed by fresh juniors (because it is).

I'm not sure where you've been looking, but source tarballs have been available from both gnu.org and the GDB website for over 20 years, with every major release going back 30 years available for download.

> Most people who use C nowadays are students, not "moderately skilled developers".

That seems a very dubious claim, especially since most students begin with Python or JS. Do you have any data to back that up?

I don’t quite understand where this is going nor why. This little sub-thread stemmed from a good tool that does already exist, and from unsubstantiated claims that C devs are students and that the simple build steps are too hard for most people. Sure, a lot of software is written by junior devs but that has no bearing on whether gdb exists, or even how hard it is to build. We have lots of good debuggers, and luckily it only takes a few experts to write them, which is why we do have them in practice.

> This little sub-thread stemmed from a good tool that does already exist, and from unsubstantiated claims that C devs are students and that the simple build steps are too hard for most people.

It's next to impossible to properly source any claim in this area; as for a lighter standard of substantiation, C wasn't a big deal in university courses 15 years ago, so it's unlikely to suddenly become it now.

N=1, but back then, between C++ and Java courses jumping straight to IDEs (to focus on language instead of build steps), and Unix/C course sticking to direct calls to GCC, at least my year at my uni managed to go through 5 years without much exposure to make and Makefiles...

Anyway,

> Sure, a lot of software is written by junior devs but that has no bearing on whether gdb exists, or even how hard it is to build.

But it does have a bearing on GDB evolution and GDB GUIs, which almost universally expose less than the bare minimum of useful GDB features; of those that expose more, I'm yet to find one that works.

> We have lots of good debuggers, and luckily it only takes a few experts to write them, which is why we do have them in practice.

Well, yes. WinDbg, that debugger in Visual Studio, etc. :). GDB, too.

My point here is that, for better or worse, size and type of the target audience determines how much and what kind of attention the project gets. "Skilled, experienced developers" are a small niche; the vast majority of developers are fresh juniors (per the growth argument), creating pressure to satisfy them at their level. Which, for GCC, I guess it means the build steps remain arcane even relative to other GNU projects, and powerful GUI frontends for it are not a thing.