Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Insights – See your source code with the eyes of a compiler

github.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: C++ Insights – See your source code with the eyes of a compiler

#41

Post by otabdeveloper4 »

JonChesterfield wrote: post #34
mgaunard wrote: post #29

Earlier quoted context omitted.

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.

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.

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.

Re: C++ Insights – See your source code with the eyes of a compiler

#42

Post by CyberDildonics »

otabdeveloper4 wrote: post #40
jstimpfle wrote: post #19

Earlier quoted context omitted.

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…

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.

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.

Re: C++ Insights – See your source code with the eyes of a compiler

#43

Post by jstimpfle »

otabdeveloper4 wrote: post #41
JonChesterfield wrote: post #34

Earlier quoted context omitted.

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.

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.

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.

Re: C++ Insights – See your source code with the eyes of a compiler

#44

Post by flohofwoe »

otabdeveloper4 wrote: post #40
jstimpfle wrote: post #19

Earlier quoted context omitted.

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…

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.

Optimizations usually don't change the behaviour of a program (unless you hit UB, but that's what UBSan is for).

Re: C++ Insights – See your source code with the eyes of a compiler

#45

Post by flohofwoe »

mgaunard wrote: post #29
jstimpfle wrote: post #19

Earlier quoted context omitted.

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…

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.

GDB behaves like any other debugger when it comes to optimized versus unoptimized builds. Debugging an optimized build is possible in any debugger, but your debugging information no longer maps exactly to compiler output, making source-level debugging harder.

Re: C++ Insights – See your source code with the eyes of a compiler

#46

Post by flohofwoe »

otabdeveloper4 wrote: post #41
JonChesterfield wrote: post #34

Earlier quoted context omitted.

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.

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.

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).

Re: C++ Insights – See your source code with the eyes of a compiler

#47

Post by jpc0 »

JonChesterfield wrote: post #34
mgaunard wrote: post #29

Earlier quoted context omitted.

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.

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.

> 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.

Re: C++ Insights – See your source code with the eyes of a compiler

#48

Post by trentnelson »

jstimpfle wrote: post #19
pjmlp wrote: post #14

Earlier quoted context omitted.

Even C doesn't map any longer when taking into consideration -O3, UB, vector units, and compiler replaced standard library calls. I miss the part of what a modern debug lacks.

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…

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.get() a million times whilst debugging.

Re: C++ Insights – See your source code with the eyes of a compiler

#49

Post by [deleted] »

pjmlp wrote: post #14
johnea wrote: post #2

I wonder how helpful it is for g++? Myself and my ancient h/w and s/w engineering friends have been having a discussion recently about how the modern C++ language features are generating code that is not readily debugged at the source level. The compiler has always created assembly that implements the feature described by teh high level language, but histoirically these have had a relatively one-to-one relationship w…

Even C doesn't map any longer when taking into consideration -O3, UB, vector units, and compiler replaced standard library calls. I miss the part of what a modern debug lacks.

[deleted]

Re: C++ Insights – See your source code with the eyes of a compiler

#50

Post by otabdeveloper4 »

flohofwoe wrote: post #46
otabdeveloper4 wrote: post #41

Earlier quoted context omitted.

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.

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).

> 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.

Post reply on HN