5 ms·

Don't debug -O3, or -O2 for that matter. Debug a separate debug build without optimizations, or don't heavily optimize your release build if you want to debug t

Don't debug -O3, or -O2 for that matter. Debug a separate debug build without optimizations, or don't heavily optimize your release build if you want to debug that (you know that obviously). Even with optimizations disabled, debugging C++ can be quite painful. Only add a little template stuff to the source code, and a few "zero-cost" methods like indexing operators or cast operators, and it quickly becomes painful to step through code. There should be a way to avoid stepping through boilerplate methods, but apart from specifying string patterns to exclude methods by name -- not inline with the method but in a separate debugging configuration (which is very very annoying). The only solution I know is to use C++ features very lightly. Any other practical options? Check this link and the twitter posts linked there, other well known developers have this issue: https://developercommunity.visualstudio.com/t/std::move-and-similar-functions-resu/1681875?q=%5BFixed+In%3A+Visual+Studio+2022+version+17.5+Preview+2%5D https://developercommunity.visualstudio.com/t/std::move-and-...

pjmlp 3y ago
Use modern IDEs with features like Just My Code, which already help a lot. https://learn.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2022#BKMK_C___Just_My_Code https://learn.microsoft.com/en-us/visualstudio/debugger/just... Also, there are scenarios where debugging without optimizations isn't an option. The issue with std::move has been solved for a while and was a VC++ bug, not C++. https://devblogs.microsoft.com/visualstudio/a-year-of-cpp-improvements-in-visual-studio/ https://devblogs.microsoft.com/visualstudio/a-year-of-cpp-im...
- jstimpfle 3y ago
  Can Just My Code help if it is precisely my code that I want to skip over? I believe it does not -- IIUC it works based on modules i.e. the DLL that contains the machine code. IOW it doesn't even help if I move the "zero-cost" stuff to a separate source file -- templates and other stuff that have to be instanciated or inlined won't be separable from the code that I want to debug based on the module they're running in. > Also, there are scenarios where debugging without optimizations isn't an option. There are scenarios where debugging isn't an option in the first place. Doesn't mean that I should have to suffer in the typical case where debugging with no or only light optimizations is perfectly viable. An acceptable solution I guess would be to have a [DebuggerHidden] function attribute as I found for C#. Didn't find one for C++.
  - pjmlp 3y ago
    Well, if we are going down tiny details about what to skip, there are lots of C preprocessor stuff, standard library functions implementated in crazy ways for ISO/POSIX compliance, and own abstractions/functions, that I might also want to skip over.
    - jstimpfle 3y ago
      Well, don't go down that path. Stop bringing decreasingly relevant points. You are too argumentative. "standard library functions implemented in crazy ways" is what I though about once in my life, when writing a toy compiler whose output was linked to libc. Such "crazy functions" do exist but but apart from libc having little relevance in this context it's not at all like debugging a line my_arr[i] = make_arr_elem(). That is a reasonably looking line but can easily contain two more function calls than is immediately visible, and it's very very tiring in actual practice to step through such code. The only solution I've found is to be careful to use very little such magic. The general way that C is written in practice is that you don't have 3 function calls per line. So even if you have lots abstractions and macros in place that you would like to ignore (which can happen, but it's more rare than common) you can still skip over them (e.g. F10 in VS).
  - gpderetta 3y ago
    [[gnu:: artificial]]
    - jstimpfle 3y ago
      cool!
- deleted 3y ago
  [deleted]
mgaunard 3y ago
You need to be able debug optimized builds. That's a requirement of the real world if you're a software engineer. Just learn how to use gdb, it's quite capable.
- JonChesterfield 3y ago
  The complaint above isn't that gdb is hard, it's that the binary with debug info doesn't correlate very well with the source code after optimisations. Bugs tend to disappear on me when I change the optimiser flags or run the thing under gdb though. I've also had a program valgrind-clean that segfaults when run without valgrind. It's a confusing world out there.
  - otabdeveloper4 3y ago
    Just accept the fact that -O3 is the real compiler, and -O0 is the training wheels you might only use once or twice while learning to program.
    - jstimpfle 3y ago
      Not a fact. It's typical to have debug and release builds, and possibly other flavors. Of course sometimes all you have is a stack trace from a release build, and then you need to debug that. But if you can, debug the debug build, it's much easier.
    - flohofwoe 3y ago
      Frankly, that's stupid advice. Typically you have at least two build modes, debug and release. Debugging without optimization is easier because the source code maps to the compiler output, also a program without optimizations behaves the same as with optimizations, unless you put undefined behaviour into your code (should be a rare thing for an experienced programmer) or hit a compiler bug (also quite rare).
      - otabdeveloper4 3y ago
        > Typically you have at least two build modes, debug and release. Legacy cargo-cult holdover from the 1980's. No real reason for it today. > also a program without optimizations behaves the same as with optimizations Not when you want to debug it.
otabdeveloper4 3y ago
Extremely bad advice. There is no point in debugging something that bears no relation to the software you release, and compiler optimizations is the only reason to use C or C++ in the first place.
- CyberDildonics 3y ago
  It's extremely good advice. Debugging is all about simplifying things and finding the problem. Deal with your program without optimizations first. Once that is set, then you can deal with any differences due to optimizations, which should be extremely rare, because that would be a bug anyway. Mixing two sources of complexity is extremely bad advice.
- flohofwoe 3y ago
  Optimizations usually don't change the behaviour of a program (unless you hit UB, but that's what UBSan is for).
trentnelson 3y ago
This has made stepping through C++ in gdb slightly less painful for me: use gdb's skip command. E.g., in my ~/.gdbinit: # C++ stdlib skip -gfi /home/trent/mambaforge/envs/td/x86_64-conda-linux-gnu/include/c++/10.3.0/\* skip -gfi /home/trent/mambaforge/envs/td/x86_64-conda-linux-gnu/include/c++/10.3.0/*/* skip -gfi /home/trent/mambaforge/envs/td/x86_64-conda-linux-gnu/include/c++/12.3.0/\* skip -gfi /home/trent/mambaforge/envs/td/x86_64-conda-linux-gnu/include/c++/12.3.0/*/* # tl::expected skip -gfi /home/trent/.cache/cpm/expected/5acc53468c550d1f25ce819a675b60bfa0bbc69d/include/tl/\* It's not perfect, but at least I don't have to step through annoying things like std::unique_ptr<Foo>.get() a million times whilst debugging.

pjmlp 3y ago

Use modern IDEs with features like Just My Code, which already help a lot. https://learn.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2022#BKMK_C___Just_My_Code https://learn.microsoft.com/en-us/visualstudio/debugger/just... Also, there are scenarios where debugging without optimizations isn't an option. The issue with std::move has been solved for a while and was a VC++ bug, not C++. https://devblogs.microsoft.com/visualstudio/a-year-of-cpp-improvements-in-visual-studio/ https://devblogs.microsoft.com/visualstudio/a-year-of-cpp-im...

jstimpfle 3y ago
Can Just My Code help if it is precisely my code that I want to skip over? I believe it does not -- IIUC it works based on modules i.e. the DLL that contains the machine code. IOW it doesn't even help if I move the "zero-cost" stuff to a separate source file -- templates and other stuff that have to be instanciated or inlined won't be separable from the code that I want to debug based on the module they're running in. > Also, there are scenarios where debugging without optimizations isn't an option. There are scenarios where debugging isn't an option in the first place. Doesn't mean that I should have to suffer in the typical case where debugging with no or only light optimizations is perfectly viable. An acceptable solution I guess would be to have a [DebuggerHidden] function attribute as I found for C#. Didn't find one for C++.
- pjmlp 3y ago
  Well, if we are going down tiny details about what to skip, there are lots of C preprocessor stuff, standard library functions implementated in crazy ways for ISO/POSIX compliance, and own abstractions/functions, that I might also want to skip over.
  - jstimpfle 3y ago
    Well, don't go down that path. Stop bringing decreasingly relevant points. You are too argumentative. "standard library functions implemented in crazy ways" is what I though about once in my life, when writing a toy compiler whose output was linked to libc. Such "crazy functions" do exist but but apart from libc having little relevance in this context it's not at all like debugging a line my_arr[i] = make_arr_elem(). That is a reasonably looking line but can easily contain two more function calls than is immediately visible, and it's very very tiring in actual practice to step through such code. The only solution I've found is to be careful to use very little such magic. The general way that C is written in practice is that you don't have 3 function calls per line. So even if you have lots abstractions and macros in place that you would like to ignore (which can happen, but it's more rare than common) you can still skip over them (e.g. F10 in VS).
- gpderetta 3y ago
  [[gnu:: artificial]]
  - jstimpfle 3y ago
    cool!
deleted 3y ago
[deleted]

mgaunard 3y ago

You need to be able debug optimized builds. That's a requirement of the real world if you're a software engineer. Just learn how to use gdb, it's quite capable.

JonChesterfield 3y ago
The complaint above isn't that gdb is hard, it's that the binary with debug info doesn't correlate very well with the source code after optimisations. Bugs tend to disappear on me when I change the optimiser flags or run the thing under gdb though. I've also had a program valgrind-clean that segfaults when run without valgrind. It's a confusing world out there.
- otabdeveloper4 3y ago
  Just accept the fact that -O3 is the real compiler, and -O0 is the training wheels you might only use once or twice while learning to program.
  - jstimpfle 3y ago
    Not a fact. It's typical to have debug and release builds, and possibly other flavors. Of course sometimes all you have is a stack trace from a release build, and then you need to debug that. But if you can, debug the debug build, it's much easier.
  - flohofwoe 3y ago
    Frankly, that's stupid advice. Typically you have at least two build modes, debug and release. Debugging without optimization is easier because the source code maps to the compiler output, also a program without optimizations behaves the same as with optimizations, unless you put undefined behaviour into your code (should be a rare thing for an experienced programmer) or hit a compiler bug (also quite rare).
    - otabdeveloper4 3y ago
      > Typically you have at least two build modes, debug and release. Legacy cargo-cult holdover from the 1980's. No real reason for it today. > also a program without optimizations behaves the same as with optimizations Not when you want to debug it.

otabdeveloper4 3y ago

Extremely bad advice. There is no point in debugging something that bears no relation to the software you release, and compiler optimizations is the only reason to use C or C++ in the first place.

CyberDildonics 3y ago
It's extremely good advice. Debugging is all about simplifying things and finding the problem. Deal with your program without optimizations first. Once that is set, then you can deal with any differences due to optimizations, which should be extremely rare, because that would be a bug anyway. Mixing two sources of complexity is extremely bad advice.
flohofwoe 3y ago
Optimizations usually don't change the behaviour of a program (unless you hit UB, but that's what UBSan is for).

trentnelson 3y ago

This has made stepping through C++ in gdb slightly less painful for me: use gdb's skip command. E.g., in my ~/.gdbinit: # C++ stdlib skip -gfi /home/trent/mambaforge/envs/td/x86_64-conda-linux-gnu/include/c++/10.3.0/\* skip -gfi /home/trent/mambaforge/envs/td/x86_64-conda-linux-gnu/include/c++/10.3.0/*/* skip -gfi /home/trent/mambaforge/envs/td/x86_64-conda-linux-gnu/include/c++/12.3.0/\* skip -gfi /home/trent/mambaforge/envs/td/x86_64-conda-linux-gnu/include/c++/12.3.0/*/* # tl::expected skip -gfi /home/trent/.cache/cpm/expected/5acc53468c550d1f25ce819a675b60bfa0bbc69d/include/tl/\* It's not perfect, but at least I don't have to step through annoying things like std::unique_ptr<Foo>.get() a million times whilst debugging.