A broken ncurses text gui debugger with broken navigation and byzantine commands should somehow make us look more favorably upon gdb? We had better debuggers than this in the early 80s. Turbo pascal had a decent debugger and IDE that was right built in!
How come the open source world hasn't been able to create a debugger that's as good as the (still primitive) debugger in Visual Studio 6.0? It's astonishing to me how bad the state of the art is.
Without question, Windows has the best debugging facilities. windbg is the best debugger, and when you have source code, visual studio's debugger is super nice. But guess what, windbg has so many commands that it's kind of hard to use for newbies and there's some great commands that even experts don't know about unless you go digging. This is many ways is like the bad UI in gdb. Over time, you learn.
Unfortunately, we're stuck with gdb, and improving it or making a new debugger requires massive effort and likely backing by one or more organizations (e.g. lldb has apple).
The ugliness of gdb won't change, but this presentation isn't about gdb's shortcomings -- it's about a "version" of gdb that supports reverse-debugging, which is really awesome.
I use undodb-gdb all the time and it's amazing. Consequently, I use gdb all the time. The result is that over time I've learned to deal with gdb's ugliness and so I get used to it. It's similar to complicated or hard-to-discover user interfaces in GUI programs.
> improving it or making a new debugger requires massive effort
Seeing what a single person (Greg Clayton) has done with his gui experiment for lldb (just run lldb and type "gui" command), I'm not sure the effort is so massive. Rather it's the fact that OSS developers have a really weak spot when it comes to design a good UI.
How so? I saw this suggested in some places but I found windbg atrociously complicated, even compared to plain GDB. It can debug the windows kernel, but that's about the best I can say about it. x64dbg and IDA's debugger were far nicer to work with for all desktop reverse engineering purposes.
In terms of non-RE debuggers, yeah, VS's is pretty good, but I don't find it that much better than anything else to say it's a must-have. Most source-level debuggers offer about the same feature set in only slightly different ways. It does the job and once you know one you pretty much know them all.
The UI is pretty bad but the commands are extremely powerful. It has commands and plugins to help you find deadlock, list out all system locks in a process, who owns them, layouts of data structures and lots more.
> "Unfortunately, we're stuck with gdb, and improving it or making a new debugger requires massive effort and likely backing by one or more organizations (e.g. lldb has apple)."
Being stuck with gdb doesn't mean you can't do those things in IDEs though. Visual Studio has a gdb front end so you can run gdb on the target and debug in Visual Studio.
Since VB is mentioned I guess I can mention another language that have good open source debuggers:
Java.
For all its warts Java has a pretty decent open source community and many of the best tools in Java land are open source.
For example all the three major IDEs are available in open source versions, two of them are completely open source (although you can get commercial plugins) and all have decent debuggers.
Yes. The one thing I miss from Java development the most is debugging code from IntelliJ IDEA. Its just a fantastic experience to be able to step through line by line and see what's really going on, where it branches on each iteration and what state is changed. IntelliJ shows the current values of each variable next to where they are used in the source view, which really helps to narrow down the variables which are currently important.
The debugger that is available in JetBrain's CLion IDE provides a good chunk of the IntelliJ IDEA debugger interface for C/C++. Likewise, AppCode does the same for Objective-C. They wrap around LLDB.
Hear hear! This is, however, because the VM abstracts the bulk of the low level nastiness and exposes a reasonable API, which reduces the effort involved by an order of magnitude.
>> How come the open source world hasn't been able to create a debugger that's as good as the (still primitive) debugger in Visual Studio 6.0? It's astonishing to me how bad the state of the art is.
I keep asking myself that same question every now and then, why can XCode have such a nice and pleasant LLVM-based version of gdb, while gdb on linux still doesn't have even the most bare-bones GUI that let's me inspect common data types without jumping through hoops?
On Xcode nowadays the debugger is lldb, not gdb, but it's a very similar debugger in the sense that it's fundamentally command-line-based. Xcode just happens to integrate with it to provide a GUI front end.
When I was into Linux in the '90s, DDD was very popular (as was Emacs as a gdb front-end), but now there are also dedicated IDEs like Develop/QT Creator/Eclipse that provide similar front ends to gdb like Xcode does for lldb (and used to do for gdb).
It's also very valuable to learn the CLI (both for gdb and lldb), because it seems like there are inevitably useful features in both debuggers that aren't exposed by any GUI, not to mention being able to debug something over ssh. It's not a requirement though, there are tons of options out there.
This is strictly true, of course. But it's a very useful CLI, which is exposed within Xcode as well. From a developer perspective, it's a very similar situation- the CLI gives you full access to the capabilities of the debugger, and the GUI gives you more convenient/intuitive access to a subset of that functionality. Even inside Xcode I spend as much or more time in the lldb console window than I do driving it with the GUI.
I use ddd, but I don't particularly like it. It's telling that after all those years we still don't have anything better, it seems like ddd today is still the same crutch as when I first used it, over 10 years ago.
The market has spoken in terms of preferring free tools. I personally think that is one big reason why the quality of developer tools is as low as it is.
For some reason the equality seems to hold for most applications with a complex user interface. Reasons may include that it is a cross discipline thing that requires skills/people such as interaction designers, artists, technical writers, linguists etc that are less common than developers in the OSS community. It could also be that good interface design benefits from a centralized decision process which can be a bad fit for OSS that is usually too incremental and democratic for radical design changes. Normally there is no money for things like paid UI testing/focus groups.
That said, there is great free software with good UI/UX too - only they are more or less always backed by a large corporation.
A market with only free offerings will cause a certain category of actors to be absent. I would think that a market with fewer categories of actors would correspond into a drop in quality among some dimensions.
At least GDB mostly works. LLDB constantly falls over for me doing even the most basic of tasks. Give me a functioning debugger over a pretty one any day.
A year ago I would've agreed with you, but lldb seems just as solid these days. I use lldb just about every day in all sorts of oddball, convoluted debugging scenarios, and I just haven't been hitting the issues I used to with it.
It's not perfect- there are still rare situations in which it's not using the right symbols, but at least that I can usually fix that with a 'target symbols add'. Otherwise it's because the thing I'm trying to debug is sandboxed or otherwise protected, which is almost always going to be a hassle, and requires workarounds outside of the debugger. Raw lldb is a lot better than it used to be though.
GDB mostly works for x86. I used to swear at GDB many times daily when using it to debug an embedded ARM target with openocd a few years ago.
Very frustrating when it crashes just as you've got the target into the state where you think your bug will trigger. And then GDB repeats the performance reliably for you... On those days you end up resorting to a lot of creative thinking.
>> let's me inspect common data types without jumping through hoops?
could you elaborate on what's missing in GDB? data-types are written in the binary by the compiler (dwarf format), and GDB does nothing more / nothing less than parsing it and giving access to it through it user interface.
GDB has no knowledge about your code or it's library in itself (at least in C, Python extentions now include libc++ data-type-specific pretty-printers)
That is exactly what is missing in GDB. The most common things you do while debugging are treated as exotic special cases. Every other debugger I've ever used tries to show me the environment I've landed in, giving me context I can use to understand program state. That is, so far as I'm concerned, the first and most important job a debugger is supposed to do. GDB shows me nothing; I have to tug every scrap of knowledge out of it individually, and I have to tell it how this work should be done. Instead of feeling like I'm using a tool that helps me and does some of the work for me, enhancing my awareness, it feels like I'm fighting with a tool that wants to make my life difficult, that is grudgingly giving up scraps of jealously-guarded information only when I can prove my worth by guessing and reciting its arcane incantations.
I rarely bother; it's easier to fprintf() and read the log file, and this has the advantage of also working when you're trying to debug asynchronous processes.
QtCreator has a nice GUI over the GDB. I was pleasantly suprised to see it worked really well, but - on the other hand - I didn't use it for any advanced debugging.
Amen! And it makes you wonder what it's doing to our young programmers? I first used gdb in college and had I not already been using Turbo Pascal and Lightspeed C's debuggers, I would probably would have decided that debugging was too much trouble. I see this a lot on Stack Overflow, too. People writing fairly complex code who don't know how to check the value of a variable in the debugger. It's both shocking and depressing.
Because most people using 1% of the functionality of even a debugger like gdb, if they're aware it exists in the first place.
A debugger is something that helps sell an IDE by padding the feature list more than something most people will use much.
I'm not saying it ought to be like that, but in more than two decades of watching developers work, my conclusion is that most developers 1) are unfamiliar with debuggers, 2) if they do know about debuggers they rarely use them, 3) if they do use them, they rarely use more than the very basics .
I myself fall in category 3. I use gdb, and I'm fine with that because all I tend to use is going up and down the stack, displaying some expressions and occasionally single-stepping.
I've used Visual Studio, and I've used DDD, and frankly I fall back to the above because it's quick, and because it's very rare that spending lots of time in the debugger is as helpful as writing more test cases or spending more time reasoning about the code.
To displace more primitive debugging techniques, a debugger will need to be extremely quick to cut to the core of the problem and basically help automating what is often a very basic workflow to try to narrow down things like "that crash happened because of an incorrect value in x; when did x get that value and what contributed to that?" followed by "how did y get that value that contributed to the broken value in x".
You can provide lots of fancy ways of making those kind of steps more pleasant, but they're doing too little to beat having a very minimal UI to deal with.
Instead debuggers appears to largely have focused on making those hair-pulling frustrating and long but also exceedingly rare debugging sessions more pleasant.
At least that's my impression: 99.9% of the time, I need something that's a smidgeon above a printf; 0.1% of the time I get frustrated enough to consider looking at more advanced tools, but that's not often enough to usually be worth it.
A debugger is something that helps sell an IDE by padding the feature list more than something most people will use much.
Because you have the most experience in environments where debuggers can only reach a small fraction of their potential. (Barely better than printf) Let me assure you that there are very different environments out there, and have been for decades.
I don't see how that would change anything I said. I never claimed that there aren't people who will use debuggers more fully, because clearly there is. But most people won't. And I'd be very interested about hearing about these "very different" environments - I've worked on tiny embedded systems, and large distributed systems, and desktops, and a wide range of other varied systems, and personally I've never felt compelled to dig into more advanced debugger features. Not that I haven't wanted them - but what I'd like to see is not what debuggers tends to offer.
(What I'd like to see is more context aware automation of the environment; e.g. debugging a crash? I'd like to see attempts at tracing values backwards, and options for attempting to re-try runs with automatically added probes based on the state of the environment when it crashed; done right, that's save me time)
>How come the open source world hasn't been able to create a debugger that's as good as the (still primitive) debugger in Visual Studio 6.0? It's astonishing to me how bad the state of the art is.
Because nobody has hired developers to work on it. Most large scale projects (whether OSS or Proprietary) get done when someone bankrolls the development. And I suppose the reason nobody has hired developers is because its hard to make money on open source debuggers.
GDB development is driven mostly by Redhat and Mentors Graphics (ex Code Sourcery), and both of them often add new functionnalities, fix bugs and maintain GDB. But maybe their work is at too low level for most people to notice?
I still wonder what's missing in GDB. I got quite proficient with this tool, and never had access to VS. I personnally don't count GUIs built on top of GDB, as they don't provide new capabilities, just 'fancier' interfaces that GDB's CLI.
Back when I coded C a lot, I'd use DDD. It had an ugly, but functional UI, that supported editing and recompilation. DDD itself supposedly works with a variety of debugger back ends (eg pydb), but I only used it with gdb and C.
20 years later apparently it's still maintained, even if it has plataeued.
Personally, I'd like to see a more modern frontend made, perhaps for Atom.
It often feels like (as a non-emacs, non-vi user), that every conversation ever will end up at some point with a post that says "use emacs" or "use vi".
These tend to have zero actual content (emacs is a text editor. How would I use it with gdb?), and not provide any evidence, or guidance.
Emacs would split the terminal screen, showing the gdb interpreter/prompt in the bottom pseudo-window where you could interact with it, and the source code for the current function in the top "window", with a visual "pointer" at the current line.
I know you could put watch expressions into gdb, and I suspect there was a way to pull these into another emacs text window, as well.
Gdb also had commands to list the stack and select a frame further down to see the callers data. I don't remember if the source code view (in emacs) would track the selected frame.
You just run it like any other interaction. In emacs if I want to compile a file I type M-x compile, and it asks me how. That creates a new buffer in which errors are linked to the original buffer. M-x gdb works the same way.
You seem obsessed with other people's downvoting. Relax, seriously. If you think someone got a downvote they didn't deserve, upvote it yourself and move on. It's not your responsibility to police other people's voting behavior.
Edit: If it really bugs you that much, post a comment backing the person up, but don't bring up the votes. It never adds anything except drama and distraction.
I recently switched from doing my C/C++ debugging in gdb to Eclipse here are some of my thoughts:
-> Eclipse can be easily be started from the command line - e.g. "cdtdebug.sh -e ./a.out". A minimal version of Eclipse opens up, and you can immediately step through code, no need to create projects.
-> While GDB TUI mode somewhat mitigates the issue of not having context when debugging it IMHO pales in comparison to seeing the full file in Eclipse.
-> In Eclipse I can see so much more information than gdb. I can see several expressions all being updated, memory views, I can highlight expressions in code. With gdb I could only ever see one thing at a time.
-> Although GDB has more functionality than Eclipse, I found since I couldn't remember certain GDB commands and so I just didn't use certain features that I find myself constantly using in Eclipse because it's just a click away.
Yeah, I've had decent luck with both Eclipse and Qt Creator's interfaces. There's also excellent debuggers for Python like WinPDB. GDB itself has reverse debugging support which could be integrated into IDEs... https://www.gnu.org/software/gdb/news/reversible.html
Priorities and Laziness. Open source produces some amazing stuff because of laziness. It also produces a lot of "good enough" stuff because of laziness.
If you count interpreted languages, then there are plenty of killer debuggers for JavaScript, at the very least. Chrome dev tools is just as good (probably better if you count all the tabs) as I remember Visual Studio's debugger being.
In his defence, he didn't say he'll make you think gdb is the greatest, just change your perspective of it. A broken ncurses text gui debugger is miles better than viewing your code via basically ed commands. If all you have is gdb, then knowing how to use it more productively is certainly welcome. That's the situation with e.g. embedded development or debugging the kernel via a serial interface.
It's still kind of crappy, but at least it's not ed.
I almost always use gdb from Eclipse but it's nice to be able to ssh into a small system without GUI and still get baseline functionality, kind of like how I use vi.
That's fine for relatively simple code that you have written yourself, but is crap if you are trying to get an idea of how someone elses complex application works.
How come the open source world hasn't been able to create a debugger that's as good as the (still primitive) debugger in Visual Studio 6.0? It's astonishing to me how bad the state of the art is.