Yes. It can print the value of C variables and Python objects, using their _str() method I assume. Extremely useful. Even better when done within Emacs.
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.
> "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.
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.
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.
>> 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)
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.
>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.
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.
IMHO, In this day and age, a proper debugger should by default show source code and execution point, should allow you to inspect variables, and change its values, you should be able to manually set the executing position, and you should be able to alter code and re-compile on the fly, continuing the debugging session.
I know this is really-really hard to accomplish, but some IDEs do it.
The only thing that's "optional" and a little over the top (but very useful) is time-travel debugging.
When you say "alter code and re-compile on the fly," do you mean and continue debugging without stopping the app and re-running? Because if so, that's a terrible way to debug. You now have state that may not be possible to achieve with the new binary you've made, and you may be debugging something that won't every exist in reality. And it may be very hard to tell that's the case. That doesn't sound very useful. It sounds very dangerous.
I find that's exactly where the debugger is most useful. I know I'm trying to reach or examine a state that my binary can't achieve. That's the problem. The debugger lets me poke around to figure out what exactly is wrong with my state, faster and more immersive than recompiling and rerunning every time. Then I fix the binary to match.
It occurs to me now that's essentially using the debugger as a REPL, but with access to a whole runtime's worth of external state. That's not a bad tool to have in your box.
If you're in a codebase composed largely of side-effect free functions or well encapsulated Object Oriented code, it's a very good way to debug. I had great success with such debugging and even coding and new development in Smalltalk environments for over a decade.
On the other hand, if your codebase is full of side effects and doesn't have good encapsulation (perhaps there's a lot of fiddling with globals) then you're going to have a bad time. But to me this isn't because the debugging method is bad. To me, it's because your codebase is designed with lots of tight coupling and side effects. You have an architecture that makes it harder to reason, debug, and refactor your code. This isn't just spouting. I'm basing this on many years of experience. And yes, I saw both kinds of Smalltalk code, and the effect is exactly as I described. Guess which codebases were more productive?
I believe Visual Studio does this by simply rewinding to the function entry point which addresses most of the concerns you've raised. A debugger is just an aid to reasoning about your code, not a substitute for it.
You might make the same argument against unit tests, or little hacks you write to separate out a problematic piece of code from an even more complicated context.
If you've never written code in a live debugger session, moved the execution point back up, and immediately run over the code you just wrote, you have a crappy debugger. VB6 could do this, Smalltalk does this, it's not dangerous, it's damn productive.
There is all of this excitement around ideas like Light Table, allowing you to see the output of your code inline as you develop it. Being able to alter code and recompile on the fly in the debugger gives you a very similar experience.
there are some situations where execution of the rest of the program up to that point takes forever, and you don't want to have to spend however many hours/days/weeks reexecuting just for a typo. scientific computing comes to mind, with its huge simulations
Twenty-five years ago, there were commercial C environments that supported interactive coding close to what you got with Lisp or Smalltalk. There was Instant-C, Safe-C, RUN/C, CodeCenter, and a few others. The whole genre died out in the mid 1990s for various reasons. The most popular and powerful system was CodeCenter. People wanted to keep using it, but the developers couldn't handle the increased complexity of supporting C++, so they just gave up around 1996.
I only knew the one from Lucid Energize C++ after they moved out of Lisp Machines business.
IBM also had a version of C Set++ that used a Smalltalk like image database for C++ code, but they hardly managed to sell it as it was very resource hungry for hardware at the time.
It is very hard to find online references to it though, I think I read about it on Dr. Dobbs, back in the day.
A video from Energize C++ for those that never saw it
Yes if this video shows anything it's that you need a real GUI. The curse one is ok, but what's the point if nobody knows it exists and you need obscure commands just to scroll?
You scroll with the arrow keys. The "obscure commands" (ctrl-p and ctrl-n) are to get to the Previous and Next commands typed and are more or less universal in unix command line systems.
I agree with this. While also holding the opinion that the best coders internalize what is happening anyway. Ideally, you should be able to use one of these tools in a codebase you are familiar with.
I prefer Emacs GUD over the built-in GDB TUI. I actually don't understand why anyone would use the built-in TUI; you have to learn new things anyway, why not learn the Emacs interface which not only looks way better but is more reliable and has more features? The keyboard commands for the GDB TUI are even (mostly) cloned from Emacs.
But as that person in the audience says, it looks like the presenter is just not aware that the GDB TUI is a substandard version of Emacs GUD, having mostly the same keybindings.
The second half is a good combined demo of some neat GDB features though.
The biggest problem there is that you're injecting the politics of emacs into your debugging then. GUD's hooks into LLDB are still a third party package because certain parties have deemed llvm-based utilities politically inconvenient.
How is that relevant at all? LLDB is a completely different debugger. The fact that I have to download an extra package to use LLDB doesn't affect my use of GDB at all.
If LLDB eventually becomes as popular as GDB, I'm sure it will be included into core Emacs then. But I have no interest in LLDB at the moment.
Personally I use the TUI, but I completely get where your coming from - the TUI is really pretty lame for all that it does compared to all that it could do.
That said, the debugging I do is all from the command-line anyway, so all I really want is a way to quickly view the assembly and registers when I break, which the TUI does quite well.
As a note - I think the person in the audience was trying to get at the fact that gdb (like tons of cli programs) uses readline() for input. readline() can be configured to use emacs or vi keybindings, with emacs the default - hence why ctrl-p and ctrl-n work. I personally use vi keybindings, so in gdb I can use ESC, and then jk to go up and down the command history.
Is this entire set of comments suffering from people conflating the debugger with an interface to the debugger? In much the same way that sometimes people conflate their compiler with their IDE.
GDB is a fine debugger. I've never had any trouble with it at all, and I don't recall ever needing a feature in it that it didn't support but other debuggers did, although I'm not a very demanding user of the debugger; I rarely need more than some conditional breakpoints and the ability to see the value of any given variable or memory location.
If WinDbg were so much better than gdb, someone at Google would have replicated it for Linux.
I'm fine with gdb and conditional breakpoints is usually the most advanced feature I need. Only once I used bigger guns. Detecting the error meant run into conditional breakpoint A, then enable and run into conditional breakpoint B (which would have triggered a lot before A), and then inspect a variable. The problem: The error only occured sometimes. Thus automate this via Python, so gdb could auto-reexecute everything until it found the failure case again.
What I still miss is multi-process debugging. Gdb can only attach to a single process, so you need multiple gdbs to watch multiple processes and this introduces race conditions.
You've just reminded me; sometimes I need to run something under Valgrind, and upon Valgrind not liking something, sparking a break using GDB. I expect that's possible using other debuggers, but it's so, SO easy using Valgrind and GDB. So by this reckoning, GDB is the best debugger I've ever used.
I get that he's being clever at the beginning by poking fun at Windows but many of the shortcuts he talks about are available in Visual Studio and it has a much saner set of defaults and initial information. Ask anyone who did XBox and PS3 development which environment they preferred :).
The reverse debugging stuff is pretty cool though.
I'll give you that PS3 had a better CPU profiler but ProDG was a mess compared to Visual Studio. Crashes, disconnects, problems with source maps. If I remember correctly it couldn't do data or conditional breakpoints.
Compared to VS and PIX it was night and day, although you probably already knew that from my comment.
I use UndoDB a lot. It's been increadibly helpful for debugging dynamic binary translators, which in my case are x86-to-x86 JIT compilers.
I also use it for debugging unit tests for a static binary translator. When I'm unit testing, I will set a brakepoint at the reporting of a failure, look at how the native program and emulated program states diverged, then I'll use reverse execution and data/code breakpoints to go back and forth to try to figure out what went wrong. This is much better than having to restart each time.
Over the years I've found many bugs in UndoDB and they've been pretty quick to fix them. Their support is great.
I started using it as a student, on a non-commerical (i.e. free license), and it was an essential purchase for my current work.
Readit News
1. introduction to 'tui' mode in gdb (https://sourceware.org/gdb/onlinedocs/gdb/TUI.html)
2. intro to python support in gdb (if it was compiled in)
3. Demo of reverse debugging in gdb, which helps isolate a stack-corrupting bug (https://www.gnu.org/software/gdb/news/reversible.html)Deleted Comment
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.
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.
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.
Also, there's Voltron:
https://github.com/snare/voltron
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.
What about rr?
http://rr-project.org/
It's built on top of gdb, but seems to have a straightforward workflow (at first glance at least, I've not used it yet).
https://github.com/mozilla/rr/wiki/Usage
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.
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?
There are plenty of nice front ends for gdb on all platforms though, including Linux: https://sourceware.org/gdb/wiki/GDB%20Front%20Ends
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.
https://www.gnu.org/software/ddd/
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)
you mean lldb?
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.
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.
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.
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.
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.
https://www.gnu.org/software/ddd/
Deleted Comment
-> 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.
It's still kind of crappy, but at least it's not ed.
Deleted Comment
I know this is really-really hard to accomplish, but some IDEs do it.
The only thing that's "optional" and a little over the top (but very useful) is time-travel debugging.
It occurs to me now that's essentially using the debugger as a REPL, but with access to a whole runtime's worth of external state. That's not a bad tool to have in your box.
If you're in a codebase composed largely of side-effect free functions or well encapsulated Object Oriented code, it's a very good way to debug. I had great success with such debugging and even coding and new development in Smalltalk environments for over a decade.
On the other hand, if your codebase is full of side effects and doesn't have good encapsulation (perhaps there's a lot of fiddling with globals) then you're going to have a bad time. But to me this isn't because the debugging method is bad. To me, it's because your codebase is designed with lots of tight coupling and side effects. You have an architecture that makes it harder to reason, debug, and refactor your code. This isn't just spouting. I'm basing this on many years of experience. And yes, I saw both kinds of Smalltalk code, and the effect is exactly as I described. Guess which codebases were more productive?
You might make the same argument against unit tests, or little hacks you write to separate out a problematic piece of code from an even more complicated context.
There is all of this excitement around ideas like Light Table, allowing you to see the output of your code inline as you develop it. Being able to alter code and recompile on the fly in the debugger gives you a very similar experience.
IBM also had a version of C Set++ that used a Smalltalk like image database for C++ code, but they hardly managed to sell it as it was very resource hungry for hardware at the time.
It is very hard to find online references to it though, I think I read about it on Dr. Dobbs, back in the day.
A video from Energize C++ for those that never saw it
https://www.youtube.com/watch?v=pQQTScuApWk
Dead Comment
But as that person in the audience says, it looks like the presenter is just not aware that the GDB TUI is a substandard version of Emacs GUD, having mostly the same keybindings.
The second half is a good combined demo of some neat GDB features though.
https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
If LLDB eventually becomes as popular as GDB, I'm sure it will be included into core Emacs then. But I have no interest in LLDB at the moment.
That said, the debugging I do is all from the command-line anyway, so all I really want is a way to quickly view the assembly and registers when I break, which the TUI does quite well.
As a note - I think the person in the audience was trying to get at the fact that gdb (like tons of cli programs) uses readline() for input. readline() can be configured to use emacs or vi keybindings, with emacs the default - hence why ctrl-p and ctrl-n work. I personally use vi keybindings, so in gdb I can use ESC, and then jk to go up and down the command history.
GDB is a fine debugger. I've never had any trouble with it at all, and I don't recall ever needing a feature in it that it didn't support but other debuggers did, although I'm not a very demanding user of the debugger; I rarely need more than some conditional breakpoints and the ability to see the value of any given variable or memory location.
I'm fine with gdb and conditional breakpoints is usually the most advanced feature I need. Only once I used bigger guns. Detecting the error meant run into conditional breakpoint A, then enable and run into conditional breakpoint B (which would have triggered a lot before A), and then inspect a variable. The problem: The error only occured sometimes. Thus automate this via Python, so gdb could auto-reexecute everything until it found the failure case again.
What I still miss is multi-process debugging. Gdb can only attach to a single process, so you need multiple gdbs to watch multiple processes and this introduces race conditions.
Bring it, WinDbg :)
The reverse debugging stuff is pretty cool though.
I'm pretty sure if you asked anyone that did PS3/PS4 development they'll probably say ProDG.
Compared to VS and PIX it was night and day, although you probably already knew that from my comment.
I also use it for debugging unit tests for a static binary translator. When I'm unit testing, I will set a brakepoint at the reporting of a failure, look at how the native program and emulated program states diverged, then I'll use reverse execution and data/code breakpoints to go back and forth to try to figure out what went wrong. This is much better than having to restart each time.
Over the years I've found many bugs in UndoDB and they've been pretty quick to fix them. Their support is great.
I started using it as a student, on a non-commerical (i.e. free license), and it was an essential purchase for my current work.