4 ms·

The article should be named "the state of C/C++ debuggers and gdb in particular on Linux". Because there are debuggers for virtually any software ecosystem (for

by ktpsns 6y ago

The article should be named "the state of C/C++ debuggers and gdb in particular on Linux". Because there are debuggers for virtually any software ecosystem (for instance Pdb for Python) which frequently work the same cross platform. Considering gdb/Linux: I love the Kdevelop GUI front-end for gdb. It allows introspection of variables in source code at mouse hovering. Of course it also can open coredumps. The Fortran gdb is also great for debugging arrays. If you don't mind OSS, check out https://totalview.io/ https://totalview.io/ -- it is an instance of a domain specific debugger for C/C++ in HPC (massively parallel computing).

JoachimSchipper 6y ago
Eh, more particularly "the state of Zig debuggers and gdb in particular on NixOS Linux" - the author isn't wrong to want things to work, of course, but the author isn't using the most boring environment either.
- jamii 6y ago
  This is true but note that: * gdb works on zig code, so it isn't unreasonable to expect gdb frontends to also work * being on nixos might explain crashes or failing to start, but it's hard to imagine how it could be responsible for various gdb frontends not being able to set breakpoints, run to the correct line or render a pointer to an array of bytes, especially when those same features work fine in gdb * it also doesn't explain why the memory view in most frontends was buggy or didn't work at all * I also tried lldb, whose gui I couldn't operate at all, and code-lldb, whose breakage might actually be nix-related since I had to patch a binary (but the error message was complaining about invalid utf8...) I'm also happy to try non-gdb/lldb debuggers if you have any suggestions.
  - JoachimSchipper 6y ago
    Unfortunately, I don't really have a better suggestion. :-( I know Solaris has its own debugger(s?), and rr looks really useful, but I haven't worked on a platform that could run either.
    - jamii 6y ago
      I use rr pretty often. Most gdb frontends also work using rr, as long as they either have buttons for reverse-step or allow you to enter commands directly. That's why I was kind of bummed out that gede, which was the most functional debugger I tried so far, has neither.
  - usr1106 6y ago
    > gdb works on zig code, so it isn't unreasonable to expect gdb frontends to also work As they say typically in the license conditions: This software comes with absolutely no warranty. Nothing that's not tested in every release (better in every CI build) can be assumed to work. How much of a standard boring Linux distro is written in zig? (That's an honest question, not a justification or even a defense to ship broken software.) So yes, the headline is most likely misleading: It should be "The state of debugging zig binaries in NixOS." I expect that debugging a C binary on OpenSUSE[1] would give different results. [1] I picked OpenSUSE here because installing library source is very easy and to my limited experience gdb just finds it. I haven't used OpenSUSE for a while. I have never used NixOS, so no clue whether that would rank above or below average.
- soraminazuki 6y ago
  Most of the problems listed in this article seems to have nothing to do with Zig or NixOS. Why encourage finger pointing when you’re not sure about the exact reasons involved?
  - nemetroid 6y ago
    > Most of the problems listed in this article seems to have nothing to do with Zig or NixOS. How are you able to make that judgement?
taviso 6y ago
I remember TotalView releasing a product years and years ago called Memscape - Like Netscape, but for Memory. It looked like a browser, but was a sort of graphical heap profiler/leak detector. I think it wasn't as powerful as Valgrind, but you've got to give them credit for an interesting UX concept.
petschge 6y ago
And if I go to that website it encourages me to "try it for free" which makes me think I am supposed to pay for it. But ok, let's give it a try. Then I need to enable a bunch of Javascript. Eh, ok. It was recommended on HN, probably not too malicious. And than it complains: Uh oh... we couldn't load this form. The following may help you to view this form: * Are you using an ad blocker? Try whitelisting this page or disabling it * Browsing in a private or incognito window may prevent this form from loading correctly. Try viewing this page in a normal window. * If you’re using Firefox Tracking Protection may be enabled. This could prevent this form from loading. Learn how to disable it. * Try clearing your cache (including cookies). Ok, close tab. I will keep using other tool for HPC debugging... (Yes, I actually do HPC and I of course have heard of totalview. Last I heard it is also a total pain to install.)
nemetroid 6y ago
It should definitely not be called that, since the author is not debugging C or C++.
- jamii 6y ago
  I'm using zig, but there is also a fair amount of c in this project and I step into it fairly often. Gdb itself works just fine crossing between zig and c.

by ktpsns 6y ago

JoachimSchipper 6y ago

Eh, more particularly "the state of Zig debuggers and gdb in particular on NixOS Linux" - the author isn't wrong to want things to work, of course, but the author isn't using the most boring environment either.

jamii 6y ago
This is true but note that: * gdb works on zig code, so it isn't unreasonable to expect gdb frontends to also work * being on nixos might explain crashes or failing to start, but it's hard to imagine how it could be responsible for various gdb frontends not being able to set breakpoints, run to the correct line or render a pointer to an array of bytes, especially when those same features work fine in gdb * it also doesn't explain why the memory view in most frontends was buggy or didn't work at all * I also tried lldb, whose gui I couldn't operate at all, and code-lldb, whose breakage might actually be nix-related since I had to patch a binary (but the error message was complaining about invalid utf8...) I'm also happy to try non-gdb/lldb debuggers if you have any suggestions.
- JoachimSchipper 6y ago
  Unfortunately, I don't really have a better suggestion. :-( I know Solaris has its own debugger(s?), and rr looks really useful, but I haven't worked on a platform that could run either.
  - jamii 6y ago
    I use rr pretty often. Most gdb frontends also work using rr, as long as they either have buttons for reverse-step or allow you to enter commands directly. That's why I was kind of bummed out that gede, which was the most functional debugger I tried so far, has neither.
- usr1106 6y ago
  > gdb works on zig code, so it isn't unreasonable to expect gdb frontends to also work As they say typically in the license conditions: This software comes with absolutely no warranty. Nothing that's not tested in every release (better in every CI build) can be assumed to work. How much of a standard boring Linux distro is written in zig? (That's an honest question, not a justification or even a defense to ship broken software.) So yes, the headline is most likely misleading: It should be "The state of debugging zig binaries in NixOS." I expect that debugging a C binary on OpenSUSE[1] would give different results. [1] I picked OpenSUSE here because installing library source is very easy and to my limited experience gdb just finds it. I haven't used OpenSUSE for a while. I have never used NixOS, so no clue whether that would rank above or below average.
soraminazuki 6y ago
Most of the problems listed in this article seems to have nothing to do with Zig or NixOS. Why encourage finger pointing when you’re not sure about the exact reasons involved?
- nemetroid 6y ago
  > Most of the problems listed in this article seems to have nothing to do with Zig or NixOS. How are you able to make that judgement?

taviso 6y ago

I remember TotalView releasing a product years and years ago called Memscape - Like Netscape, but for Memory. It looked like a browser, but was a sort of graphical heap profiler/leak detector. I think it wasn't as powerful as Valgrind, but you've got to give them credit for an interesting UX concept.

petschge 6y ago

And if I go to that website it encourages me to "try it for free" which makes me think I am supposed to pay for it. But ok, let's give it a try. Then I need to enable a bunch of Javascript. Eh, ok. It was recommended on HN, probably not too malicious. And than it complains: Uh oh... we couldn't load this form. The following may help you to view this form: * Are you using an ad blocker? Try whitelisting this page or disabling it * Browsing in a private or incognito window may prevent this form from loading correctly. Try viewing this page in a normal window. * If you’re using Firefox Tracking Protection may be enabled. This could prevent this form from loading. Learn how to disable it. * Try clearing your cache (including cookies). Ok, close tab. I will keep using other tool for HPC debugging... (Yes, I actually do HPC and I of course have heard of totalview. Last I heard it is also a total pain to install.)

nemetroid 6y ago

It should definitely not be called that, since the author is not debugging C or C++.

jamii 6y ago
I'm using zig, but there is also a fair amount of c in this project and I step into it fairly often. Gdb itself works just fine crossing between zig and c.