zig c++ does not support exceptions on macos

[prenaux]

Zig Version

0.10.0-dev.4192+c75e8f361

Steps to Reproduce

Initially tested on 0.10.0-dev.2377+71e2a56e3, same thing happens on 0.10.0-dev.4192+c75e8f361

Same issue as #9591 but for macOS arm64 (on an M1 mbp).

yikes.cpp:

#include <iostream>
#include <exception>

int main() {
  try {
    throw std::exception();
  } catch (std::exception &) {
    std::cerr << "yikes";
  }
  return 0;
}

Expected Behavior

With clang:

$ clang++ yikes.cpp && ./a.out
yikes

Actual Behavior

With zig c++:

$ zig c++ yikes.cpp && ./a.out
libc++abi: terminating due to uncaught exception of type std::exception: std::exception
Abort trap: 6

[prenaux]

Does still work on Ubuntu 20:

$ g++ yikes.cpp && ./a.out
yikes
$ zig c++ yikes.cpp && ./a.out
yikes
$ zig version
0.10.0-dev.2377+71e2a56e3

[prenaux]

Works on Windows aswell:

$ zig c++ yikes.cpp && ./a.exe
yikes

[sagehane]

Possible duplicate of #10892 or #11422?

[prenaux]

It could be, but since this is a macos issue only it seems different. Exceptions works fine on Windows & Linux.

That being said they are other issues on Linux itself that make zig c++ not usable in prod for us. I was investigating using zig c++ to provide a clean cross-compiler for our C++ code base with the hope of introducing zig later on - and getting the benefit of being able to compile everything with the same compiler on a single CI server in the short term.

I dont have a reduced test case which is why I didn't file an issue for those, but for example backtrace() and libunwind can't match symbols at all which makes it a no-go for us since we need to print stacktrace in case of crash or run-time panic/asserts. Also we're encountering crashes in debug (-g) builds which work fine in -O1/-O2 builds (and on vanilla Clang with ASAN & GCC).

Hard to say exactly what the issue is there without diving in deeper but it looks like incorrectly initialized memory issues (based on the variable & memory values in gdb). Maybe there's some global libc++ library initialization functions that aren't called - I don't know much about glibc & libc++'s internals but I know that MSVC's CRT library hooks in initialization functions that must run before everything else without which mayhem (and early crash) ensue...

[markus-oberhumer]

@prenaux I've been playing around with the same idea, trying zig cc to build UPX for 90 different targets; see https://github.com/upx/upx-test-build-with-zig

Debug build problems are probably caused because zig cc defaults to -fsanitize=undefined when not optimizing - this is a noble idea but likely makes a very bad first impression (it catches too many common things like unaligned loads/stores). IMO this default should be reverted, at least until the the other bugs are sorted out.

Still, I think zig cc has great potential, but it definitely needs some more work.

[sagehane]

... at least until the the other bugs are sorted out ...

Are you referring to issues like these?
#10374
#11403

I guess it might be worth making a proposal or meta issue to track these, idk how much issues they present.

But aside from that, I think -fsanitize=undefined is a good default and should be kept as-is.

[markus-oberhumer]

... at least until the the other bugs are sorted out.

I'm referring to this: https://github.com/upx/upx-test-build-with-zig/actions/runs/3447041717

[prenaux]

@markus-oberhumer Thanks for the pointer, indeed -fsanitize=undefined could be the issue for the debug build crash.

If that's indeed the cause I'm not convinced it is a practical default either, we do run linters, asan, valgrind and have custom memory allocators that do memory debugging and our code runs on quite a few platforms with 0 error/warnings from all of them. - Obviously that doesn't mean there's 0 issue in our code and that -fsanitize=undefined is not pointing at some of them, but we have to pick our battles.

ASAN -fsanitize=address and Valgrind give you a descriptive error with a callstack and a bunch of other info depending of the problem. If -fsanitize=undefined only crashes your app when there's a mistake in your code it doesn't seem like a helpful default.

At the very least I would hope this to be configurable and clearly documented.