4 ms·

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/curre

• genpfault 2y ago
  Only works if GDB has been built with TUI support, sadly :(
  • cyberpunk 2y ago
    … If you are debugging c code surely you’re able to compile a debugger with whatever options you want?
    • rty32 2y ago
      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.
      • Gormo 2y ago
        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.
        • desdenova 2y ago
          Most people who use C nowadays are students, not "moderately skilled developers". Students barely know how to manually put together a Makefile.
          • dahart 2y ago
            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.
            • TeMPOraL 2y ago
              > 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).
              • dahart 2y ago
                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.
                • TeMPOraL 2y ago
                  > 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.
        • TeMPOraL 2y ago
          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.
          • ink_13 2y ago
            The GDB source is available as a standalone package: https://www.sourceware.org/gdb/download/ https://www.sourceware.org/gdb/download/
          • Gormo 2y ago
            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.
  • shortrounddev2 2y ago
    Is it not usually? I've never had to compile gdb myself to get TUI
    • sakras 2y ago
      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.
    • srott 2y ago
      Only seen on some minor embeded systems but it’s not a big deal to compile gdb with tui support enabled.
• shmerl 2y ago
  Neovim + nvim-dap + nvim-dap-ui + gdb works much nicer than that.
• marssaxman 2y ago
  How have I never heard of this before? Thank you.
• b5n 2y ago
  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