7 ms·

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 ten

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.
    - jstimpfle 3y ago
      That's a really interesting mix of wild claims and plain wrong statements.
    - CyberDildonics 3y ago
      I'm not sure where you got these ideas, but there are tons of benefits to debug builds like catching out of bounds lookups on vectors the moment they happen and faster compilation. It's bizarre that you don't realize everyone works this way. Not when you want to debug it. I think you're mistaking debug information not lining up with your program for different behavior, but these are not the same thing.
      - mgaunard 3y ago
        Debug/sanitized builds are for unit tests. Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.
        CyberDildonics 3y ago
        Debug/sanitized builds are for unit tests. What about just compiling and running your program after you make a change or get a crash? Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario. Right... What's your point? This scenario doesn't overlap with regular iterations. Normal workflow and a crash after a program is distributed are two separate things.
        mgaunard 3y ago
        The crash when your program is distributed is the normal workflow. What matters is that your program runs flawlessly in its distributed environment, not that your test suite passes locally. Testing is but a proxy to achieve the true goal, and is far from perfect.
jpc0 3y ago
> Bugs tend to disappear on me when I change the optimiser flags or run the thing under gdb though A lot of that shouts UB or compiler bug to me. I don't get this in my code unless there is some UB I missed. Unfortunately there are places where UB is unintuitive and may not even be present in newer versions of the language.
mgaunard 3y ago
Debugging optimized binaries is harder than debugging non-optimized ones, and requires more advanced debugging skills and gdb knowledge. There is a reason why crash dumps on optimized builds used to be called "guru meditation". One useful skill to get started is learning how to get at data and print it through various levels of complex C++ data structures, which might require leaning on the python API to stay sane.

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.
  - jstimpfle 3y ago
    That's a really interesting mix of wild claims and plain wrong statements.
  - CyberDildonics 3y ago
    I'm not sure where you got these ideas, but there are tons of benefits to debug builds like catching out of bounds lookups on vectors the moment they happen and faster compilation. It's bizarre that you don't realize everyone works this way. Not when you want to debug it. I think you're mistaking debug information not lining up with your program for different behavior, but these are not the same thing.
    - mgaunard 3y ago
      Debug/sanitized builds are for unit tests. Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario.
      - CyberDildonics 3y ago
        Debug/sanitized builds are for unit tests. What about just compiling and running your program after you make a change or get a crash? Crashes in production happen with optimized builds. You need to be able to inspect the core and figure out what happened from there, as usually you can't reproduce the scenario. Right... What's your point? This scenario doesn't overlap with regular iterations. Normal workflow and a crash after a program is distributed are two separate things.
        mgaunard 3y ago
        The crash when your program is distributed is the normal workflow. What matters is that your program runs flawlessly in its distributed environment, not that your test suite passes locally. Testing is but a proxy to achieve the true goal, and is far from perfect.

jpc0 3y ago

> Bugs tend to disappear on me when I change the optimiser flags or run the thing under gdb though A lot of that shouts UB or compiler bug to me. I don't get this in my code unless there is some UB I missed. Unfortunately there are places where UB is unintuitive and may not even be present in newer versions of the language.

mgaunard 3y ago

Debugging optimized binaries is harder than debugging non-optimized ones, and requires more advanced debugging skills and gdb knowledge. There is a reason why crash dumps on optimized builds used to be called "guru meditation". One useful skill to get started is learning how to get at data and print it through various levels of complex C++ data structures, which might require leaning on the python API to stay sane.