4 ms·

> We have gdb, lldb, and rr (plus about a million graphical front ends, none of which are good). Strongly agree - I've spent a great deal of time trying to fin

> We have gdb, lldb, and rr (plus about a million graphical front ends, none of which are good). Strongly agree - I've spent a great deal of time trying to find a good GUI for gdb, but it's all so janky compared to proper IDE debugging. As a result I only break out gdb as a last resort where printf statements don't do the job.

flohofwoe 2y ago
VSCode is 'quite ok' on Linux as gdb frontend. The main limitation is the really bare bones variable view panel. With the MS C/C++ and CMake Tools extensions debugging pretty much works out of the box and feels 'IDE like' (in that you can select the build and debug targets instead of writing a launch.json and tasks.json file, and starting into the debugger for the current debug target is just pressing F5). The other debugger frontend that works quite ok is QtCreator.
- ninepoints 2y ago
  Very mid compared to Visual Studio in my experience. You don't even get a modules window, and there's a whole litany of core C++ debugging features missing.
  - flohofwoe 2y ago
    Yeah, but compared to the Visual Studio debugger, pretty much everything is stuck in the stone age unfortunately.
    - jcalabro 2y ago
      I agree with this whole thread. I do use VS Code as my debugger frontend for C++ on Linux, but it's a real bummer compared to what's available on Windows. Hence this series!
immibis 2y ago
IIRC the FSF does this on purpose to ensure anything based on GDB must be linked with it and therefore GPL covered.
- deleted 2y ago
  [deleted]
- jonathrg 2y ago
  Is GPL really an impediment for someone developing a GDB frontend?
  - jcalabro 2y ago
    I don't think so since you could do a front end over DAP, right? No linking required therefore. IANAL
    - immibis 2y ago
      It was added well after GDB's design was set. Only when LLVM brought a permissively licensed competitor did the FSF start opening up its toolchain to not be left out in the race to the bottom.
khuey 2y ago
Totally shameless plug: if you like rr's technical capabilities but not it's UI, you might love Pernosco (https://pernos.co/ https://pernos.co/)
- jcalabro 2y ago
  I have poked around with Pernosco, and it's very impressive! I just added a paragraph to the intro of this series about it. Pernosco is so cool! However, I think it's aiming to solve different bugs than I am usually after. I want a very quick-to-use debugger because I like to step through all my code as I'm writing it to sanity check. It generally just helps me stay focused and make fewer errors (I'm not the most detail-oriented person in the world, and the debugger helps keep me on the rails). Pernosco/rr are invaluable tools for solving much tougher bugs, but I want a better debugger for the "every-day" sort of stuff as well. Thank you for pushing the state of the art though, Pernosco is jaw-dropping!

flohofwoe 2y ago

VSCode is 'quite ok' on Linux as gdb frontend. The main limitation is the really bare bones variable view panel. With the MS C/C++ and CMake Tools extensions debugging pretty much works out of the box and feels 'IDE like' (in that you can select the build and debug targets instead of writing a launch.json and tasks.json file, and starting into the debugger for the current debug target is just pressing F5). The other debugger frontend that works quite ok is QtCreator.

ninepoints 2y ago
Very mid compared to Visual Studio in my experience. You don't even get a modules window, and there's a whole litany of core C++ debugging features missing.
- flohofwoe 2y ago
  Yeah, but compared to the Visual Studio debugger, pretty much everything is stuck in the stone age unfortunately.
  - jcalabro 2y ago
    I agree with this whole thread. I do use VS Code as my debugger frontend for C++ on Linux, but it's a real bummer compared to what's available on Windows. Hence this series!

immibis 2y ago

IIRC the FSF does this on purpose to ensure anything based on GDB must be linked with it and therefore GPL covered.

deleted 2y ago
[deleted]
jonathrg 2y ago
Is GPL really an impediment for someone developing a GDB frontend?
- jcalabro 2y ago
  I don't think so since you could do a front end over DAP, right? No linking required therefore. IANAL
  - immibis 2y ago
    It was added well after GDB's design was set. Only when LLVM brought a permissively licensed competitor did the FSF start opening up its toolchain to not be left out in the race to the bottom.

khuey 2y ago

Totally shameless plug: if you like rr's technical capabilities but not it's UI, you might love Pernosco (https://pernos.co/ https://pernos.co/)

jcalabro 2y ago
I have poked around with Pernosco, and it's very impressive! I just added a paragraph to the intro of this series about it. Pernosco is so cool! However, I think it's aiming to solve different bugs than I am usually after. I want a very quick-to-use debugger because I like to step through all my code as I'm writing it to sanity check. It generally just helps me stay focused and make fewer errors (I'm not the most detail-oriented person in the world, and the debugger helps keep me on the rails). Pernosco/rr are invaluable tools for solving much tougher bugs, but I want a better debugger for the "every-day" sort of stuff as well. Thank you for pushing the state of the art though, Pernosco is jaw-dropping!