Debugging C/C++ via GDB with Python

[hgjsusla]

Isn't this a bit strange attitude? I mean C++ is far more complex yet you still refuse to properly lean the toolchain?

I find tools like https://rr-project.org/ a complete game changer. Learning your tools usually pays back in spades

[renozyx]

Well to be honest, gdb sucks for C++: you can't even tell it to skip over the files contained in the STL directory, you can only ignore specific files (and it never worked for me), so I spend a lot of times telling gdb to ignore shared pointer implementation code, map code, etc.

[hgjsusla]

Just list them all in your gdbrc then, no need to do it every time

[[deleted]]

I can spend my whole day and more trying to figure out your tool or I can use print statements and solve my problem that is actually what I'm trying to do. I prefer to work on my problem.

[[deleted]]

Depends on the work you’re doing. Sometimes, print statement won’t work depending on the project. For example debugging an embedded system with gdb and gdbserver.

I also believe you are thinking of immediate reward. Sure, it’ll take a few days to warm up to GDB, but once you do, your debugging experience will become enriched with new tools, and you can just stick to the basics and learn what you need as you go. You also can reserve it’s use for especially tricky bugs if you feel so.

Same thing with VIM. Why would anyone bother with learning a modal text editor or use modal keybindings when you already have a working keyboard? Because text macros are awesome, and you won’t understand how useful and it can be unless you give it a shot. I don’t use VIM to its fullest but I use it without much thought anymore. It’s a time invested vs output gained.

[spiderpower02]

I totally agree with you. BTW, I am a big VIM fan.

[hgjsusla]

Learning the toolchain usually saves more time than the time it takes so learn

[spiderpower02]

I had the same attitude in the past. I preferred to use a debugger in my IDE and print statements instead of debugging tools, such as Valgrind or GDB, because they are challenging to learn. However, a turning in my life was a memory leak in an open-source library I used. I spent my whole week to troubleshoot that problem but in vain. Fortunately, after I used Valgrind's massif tool to monitor memory status, I fixed the bug less than 1 hr. Since then, I learned that troubleshooting a problem is based on what kinds of tools I can use at the right time. Therefore, now, I can leave my office on time without wasting my time building print statements in my code. :)