Why do we build compiler-rt/libcxx/libcxxabi with RelWithDebugInfo?

[TerrorJack]

Why are we building them with RelWithDebugInfo instead of Release? Apart from lower optimization level, it causes dwarf sections to be linked into the final wasm with default linking flags, which IMHO is not desirable for most wasi-sdk users.

[sbc100]

I think if you don't want debug info in your binary you probably want to either link with -Wl,--strip or run strip (llvm-strip really) on the final binary.

The alternative is that we ship two copies of all the libraries, one with debug and one without, but that adds complexity we probably don't want.

[TerrorJack]

It seems to me that consumers of debug flavored sysroot will tend to build their own sysroot anyway (with Debug, and other custom flags). So simply changing to Release seems to be the best thing to do here?

[sbc100]

I don't have a strong opinion. It does main that anyone who builds a debug binary won't be able to step into any system functions, but maybe that fine/normal/expected?

[TerrorJack]

It does main that anyone who builds a debug binary won't be able to step into any system functions

Note that wasi-libc is already built sans debug info, and that's where most important system functions live.

[sbc100]

It does main that anyone who builds a debug binary won't be able to step into any system functions

Note that wasi-libc is already built sans debug info, and that's where most important system functions live.

I see, perhaps that should be built with debug info then? In emscripten we chose to build all libraries with debug info, and have the linker strip it when a release build is desired. It really depends how many wasi-sdk users will end up wanting to debug system library level stuff.

[TerrorJack]

Yes, the strip-at-link-time approach is reasonable. It's just that when debug info is enabled (at least via cmake RelWithDebugInfo compared to Release), the optimization level is lower and that impacts code quality for users who don't debug the sysroot.

[sbc100]

Really? I thought that point of RelWithDebugInfo was that it was the same as Release in terms of opt level but with debug into? Maybe I'm wrong?

[TerrorJack]

Really. See https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake#L59, by default Release is -O3 -DNDEBUG, while RelWithDebInfo is -O2 -g -DNDEBUG. And this is another place where wasi-libc build flags is inconsistent with the rest of toolchain, currently wasi-libc is built with -O2 -DNDEBUG. We should at least make it consistent with rest of the sysroot.

[sbc100]

We should probably be consistent about shipping debug info or not for all libraries.

Being consistent about optimization levels isn't critical I think, but it should be done deliberately. There may be some part of libc/compiler-rt/libc++ that would be best built with -O2, -O3 or -Oz.

[TerrorJack]

One thing I forgot to mention in the previous discussions: shipping sysroots with debug info doesn't really allow one to debug them, because the dwarf sections do not embed the source code (even with -g3), and only refer to source absolute paths. They are not present in the wasi-sdk tarball anyway.

[SamB]

One thing I forgot to mention in the previous discussions: shipping sysroots with debug info doesn't really allow one to debug them, because the dwarf sections do not embed the source code (even with -g3), and only refer to source absolute paths. They are not present in the wasi-sdk tarball anyway.

Okay, so that is inconvenient, but when you're trying to make sense of a stack trace you don't absolutely need to see source files in your debugger.

(Note to self: figure out how debian could ship source suitable for debugging sometime...)