CppCon 2018: Greg Law “Debugging Linux C++”
Вставка
- Опубліковано 11 жов 2024
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/Cpp...
-
Greg will demonstrate some neat new GDB features and other advanced debugging tools on Linux.
Debugging dominates software development, and yet all too often we rely on printf or at best a little bit of gdb with a bit of 'next' and 'print'. This talk will demonstrate some of the power of newer versions of GDB (Reverse debug, dynamic printf, amazing scriptability possibilities through Python), as well as some of the other Linux debugging tools at your disposal: ftrace, strace, ltrace, valgrind, rr, asan, and lots of very useful stuff in /proc.
This presentation works either as a stand-alone talk or as a follow on to Greg's popular 'GDB Power User' talk at cppcon 2016."
-
Greg Law, Undo Limited
CTO and Co-Founder
Greg is co-founder and CEO at Undo. He is a programmer at heart, but likes to keep one foot in the software world and one in the business world. Greg finds it particularly rewarding to turn innovative software technology into real business development. Greg has over 20 years of experience in both academia and innovative start-up software companies.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/reg...
*-----*
I was really hoping for a new GDB video from Greg Law.
This is exactly the kind of video I was expecting: here's what you can do and how you can do it, the practical approach video.
Thanks!
[Finished]
As a beginner to C++, I found this video to be somewhat challenging. Although the speaker introduced several helpful commands like `gdb` and `rr`, in the examples of the video they produced too much output on the console for me to keep up with. As a result, I struggled to follow the speaker's actions at times. To help other beginners like myself, it might be useful for the author to slow down the pace of the video and add more annotations to make it easier to understand.
I prefer cgdb to gdb TUI mode. It has syntax highlighting and vim-like keybindings. And I find it's display doesn't get screwed up often like gdb TUI.
Thanks for the advice.
The fact that printf is ever the right tool.....is a pretty damning statement for the current state of debugging tools.
Excellent talk! Tons of useful hands on information.
Interesting talk but I think I'll stick to IDEs like VS Code (which I think use gdb under the hood). Simply no way I can remember all this, and I don't want to think about my debugger text commands while I'm supposed to be thinking about the issue at hand. Same reason why I gave up on vim. Valgrind's and other dynamic or static analyzers are a great addition though.
Very nice! Please do one for Windows!
Seems the slide is missing from the git repo, is there a link to the slide of this presentation?
Can someone share the link to the presentation download. Can't find it on the github link.
There's always Qira (GeoHot's timeless debugger), which makes binary run time analysis so much easier to deal with when compared to gdb.
fantastic, thank you.
Super helpful!
`signal SIGINT` sends the signal from gdb to the process being debugged.
So.. what does this presentation have to do with C++ exactly? (apart from the title, and the one page he mentions pretty printers) IMO, this was 99,9% C and 0,1% C++ at best.
Do you think gdb is solely a c debugger? 🤔
The description makes it clear what the presentation is about.
I almost never use debugger in C++ after I realized you actually have to follow OOP rules. Most important of them in C++ are ownership, constructor/destructor -rule and not using raw arrays. But you can already guess what 99% of programmers don't follow.
I hope the intent of this comment wasn't to invalidate the talk. Some programs need things like raw arrays and avoid OOP for performance reasons. And if you value easy and safe code over complex and optimized code, maybe another safer language might be more appropriate.
fourth !
GDB is terrible, I wish FLOSS people were not so much against charging/paying money for SW so that somebody would make a decent debugger...
The problem is the current state of software engineering with release often, release early. This makes it almost impossible to maintain software patches. Also customers for whatever reason always want to use the latest versions. And ignorance in the language/compiler team about the importance of debugging is another serious factor. Most people don't realize how important it is.
I once maintained a ruby debugger (it would still be the best, 100 times faster then Komodo/Rubymine) but i had to give up.
try gdbui or pay for something like clion
First
Patrick TAYLOR wow guys look, an idiot below a cppcon video! :)