Back to Basics: Debugging in Cpp - Greg Law - CppCon 2023

[@dolphin2954]

Great talk! Thank you, Greg. I've been watching these Back To Basics videos for years and every time I wonder how one hour talk can simplify the life of a C or C++ developer.

[@CH4NNELZERO]

The stuff at the end looks like gold. Can't wait to try that out.

[@timhaines3877]

@27:28 - Adding debug information (here, DWARF) to a binary does not slow down it's runtime execution. But it can drastically increase the loading time. If you've ever launched ten thousand MPI jobs with a 4GB binary that only has 300MB of .text in it, you'll know what I mean. Separate debug information (dbo, dbz) will give you the nearly-zero overhead you are looking for.

[@donutsleader]

Debugging symbols are usually placed into separate segment in ELF and that segment is not marked to be loaded during dynamic linking. File size easily becomes tenfold though.

[@simonfarre4907]

​@@donutsleaderyeah. Dwarf lives in the .debug_FOO sections in the ELF binary. Loading the right segments is done in a literal instant.

[@mirrorless_mirror]

I'd say I like far more the Microsoft approach - PDB files. Something like that must be default in GCC and clang too. Currently, to achieve that, I have to run few non-trivial commands over normal executable with debug info included.

[@simonfarre4907]

If you are on Linux and using VSCode, using GDB becomes trivial with the "Midas" debug adapter extension. It also makes the use of RR and GDB seamless. I just realized every single slide had "undo" on it. Kinda obvious why they won't mention RR then 😅. RR is free and open source though, undo isnt.

[@Yupppi]

I think part of why this debugging talk is so good is because there's so many little commands and arguments and syntaxes and whatnot that went wrong in demonstrating the debugging, that it lead to debugging itself. And it perfectly demonstrates why you need a debugger when even in a thing you do all the time at home and at work and prepare for the demonstration, you still get some things wrong, because you're just a human. So you should probably take advantage of tools and not trust yourself.

[@torstenknodt6866]

Thanks, great to see all the possibilities. I worked mostly on deeply embedded systems, where you do not have executables, so this was really great. However, from the title I expected something specific to C++, like how to debug through templates and such stuff.

[@jacquesenboit6351]

Would be nice if chapters are listed. This way I can jump riggt into what's new to me.

[@empireempire3545]

his attempt at using GDB is exactly why i hate to use GDB xD It's so user-unfriendly it's crazy, especially considering typical linux command line tools

[@heavymetalmixer91]

What about LLDB?

[@simonfarre4907]

If you are on Linux and using VSCode, using GDB becomes trivial with the "Midas" debug adapter extension. It also makes the use of RR and GDB seamless.

[@UvUtkarsh]

10:47 "especially if they talk back" I see what you did there 😂😂😂

[@MalcolmParsons]

Apparently DDD has new maintainers and ddd-3.4.0 was released on 2023/05/10

[@jimcameron6803]

"How many lines of code can you type in and have it work first time?" Me: On average ... about 1/2?

[@linyuzqlby2590]

🥰

[@rasitsimsek9400]

I dont using printf in C++.

[@oisyn-]

23:45 OMG the pain. I totally couldn't relate about printf debugging, that's usually only my go to when I have to deal with too much data or events such that stepping through the code doesn't make a lot of sense yet as you don't know the exact conditions to look for. Otherwise it's just a matter of pressing F5 from the IDE. I personally never worked with GDB, or maybe on a blue monday 15 years ago or something, but if that's the interface you need to deal with to just debug your code, my god I understand how you would choose to first do some printf calls instead. Is this the state of things on linux or are there better tools available? I should hope so. (Disclaimer: I've been working with Visual Studio for the past 20 years, developing for PC and game consoles)

[@SonicFan535]

Most people would just use a GUI wrapper for gdb, like the ones in Visual Studio Code or any proper IDE, which makes it work pretty much exactly like the debugger in the regular Windows version of VS.

[@not_ever]

I had to use Visual Studio for the first time in three years yesterday and oh my god the pain. Is that the state of things in Windows? (I’m not joking this was my actual day and it ruined it). Linux has an array of debugging tools. Probably more than Windows. Also gdb can be used much more smoothly than this with a nice frontend gui or tui (not the one shown here) or in a text editor such as vscode or neovim. However some of us spend our time logging into headless servers/robots and knowing how to use gdb and other command line tools is important.

[@9uiop]

@@not_ever What's your issue with it? Honestly I think the VS debugger is pretty decent. On Linux I'm using gdb/lldb with some frontends but it never works the way I would expect to.

[@babgab]

@@not_ever VS blows away pretty much every other debugger I've ever used in terms of features and user interface. Speed and responsiveness I'll give you, I'm sure command line tools are pretty quick, but it's worth the pain for me.

[@Alexander_Sannikov]

it's a very typical story how linux people keep shitting on visual studio because of their stockholm syndrome associated with gdb. it's best to just leave them be.

[@wjrasmussen666]

I feel like I spend too much time bugging!

[@unclechaelsneckvein]

And it's so sad

[@haxhunyadi5582]

This is technically all good, but does not help at all when it comes to debugging. What people want is a pragmatic way of finding/reproducing errors. The sad truth is that there is no such way for most of the bugs.

[@benstanley9788]

You can lead a horse to water...

[@mirrorless_mirror]

Yes, really, debugging optimized binaries generated by GCC is hell. Debugger is often useless. Microsoft C++ is far better in this sense. Someone have to enforce this in compilers like clang and gcc. That would be nice.

[@ElementaryWatson-123]

I rarely debug my code, but I had to debug other people's code a lot. The most difficult cases are in two categories: multithreaded code and undefined behavior. Multithreading bugs often involve data races, I've seen code that crashed but ran fine once you put a print statement. It would be running fine in debugger, as well as with prints -- impossible to debug, have to put eyeballs to examine the code. Undefined behavior is another common cause of bugs. In that case a debug build usually works fine but optimized build would crash. It's not fun debugging optimized build. Again, eyeballing the code I found "if(this)..." statements, which I immediately knew was a bug. The same person put code with side effects in destructor, which optimizer thrown away. If you have to use debugger, memory tools, etc. too often that means you are not hiring competent programmers.

[@rasitsimsek9400]

The gdb user interface and usage is horrible :)

[@marcbotnope1728]

If you need to drop into the debugger you have done something wrong

[@ElementaryWatson-123]

... or somebody else has done something wrong. Every time I need to debug something it's because some incompetent programmers wrote horrible code.

[@babgab]

I'd love to see how you'd work out that an OS bug or even hardware bug is responsible for your code crashing on x% of your users' machines without a debugger