Exception catching is broken in JIT mode

[yfinkelstein]

try: 
	raise RuntimeError("exception is thrown")

except Exception as e:
	print(f"caught exception {e=}")

codon run excepton_test.codon

RuntimeError: exception is thrown

Raised from: 
.../exception_test.codon:2:2

Backtrace:
Aborted

However, if built first then it works:

codon build excepton_test.codon
./excepton_test.codon

caught exception e=exception is thrown

[arshajii]

Hi @yfinkelstein what platform are you on? Testing on macOS and it is working there at least... Also can you please check if except RuntimeError works or not?

[yfinkelstein]

Hi @arshajii
I'm doing it on Linux 6.8.0-64-generic
except RuntimeError: does not work either.

I wonder if it has to do with LLVM v 20 having cmake option LLVM_ENABLE_EH OFF by default.
I'm rebuilding with this option on right now and will post the result

[yfinkelstein]

No, setting LLVM_ENABLE_EH = ON did not make any difference

[arshajii]

Thanks -- is it x86? Also, is this a custom-built Codon? If so, is it possible to try the pre-built version and see if that works?

[yfinkelstein]

@arshajii it does work with official version in jit mode and yes - i'm using a custom-built one with clang/libc++ being one difference. Another it that I link with libomp statically and as a result there are no dependencies on shared libs from gcc distribution. Everything else seems to be working.

What could be causing the problem for me iyo?

[yfinkelstein]

Hi @arshajii :
I narrowed it down to this problem:

in jit mode (codon run ..) the call to _Unwind_RaiseException in exc.cpp returns:

  322  SEQ_FUNC void seq_throw(void *exc) {
-> 323    _Unwind_Reason_Code code = _Unwind_RaiseException((_Unwind_Exception *)exc);
   324    (void)code;
   325    seq_terminate(exc);
   326  }

but in stand-alone mode (after codon build ..)
this function does not return which is what it supposed to do since it's throwing an exception and is matching the handler which does exist.

So, somehow it does not match the handler in my build of codon.

Have you tried to build with clang and stdlib=c++ ? This is likely the main difference.

It's quite puzzling why it works in built mode but not in jit mode

[yfinkelstein]

The value of code returned is

p code
(_Unwind_Reason_Code) _URC_END_OF_STACK

[arshajii]

Hmm, tough to say for sure. Is it possible to adjust the build options to determine which one causes the issue? E.g.

Have you tried to build with clang and stdlib=c++ ? This is likely the main difference.

Does it work without this? Or without static-openmp? (We usually build with clang btw.)

[yfinkelstein]

@arshajii I further narrowed it down to c++ abi library on Linux. If I compile wit clang and -stdlib=stdlibc++ everything works. But if i compile with -stdlib=libc++ the exceptions are broken in jit mode.

Even more so, I have a custom build of libc++ that links with gcc's libsupc++.a and this works too. So, the issue is purely what c++ abi library is being used.

[yfinkelstein]

Update : this was caused by linking with llvm libunwind.so in the excitable that embeds codon while llvm itself was built with gcc's version of unwind. They are not compatible in the following sense:

FDE vs. CIE: In the DWARF exception handling standard, a CIE (Common Information Entry) contains shared information for a group of FDEs, while each FDE describes the unwinding rules for a specific function.
Library Incompatibility: The issue arises because libgcc_s (the default GNU unwinder on many Linux systems) can accept the entire .eh_frame section via __register_frame. In contrast, LLVM's libunwind, when built for non-Apple platforms, often expects __unw_add_dynamic_fde (which is sometimes aliased to __register_frame) to be called with a single FDE only.
JIT/Dynamic Code: This problem frequently appears when using Just-In-Time (JIT) compilers or dynamically generated code that registers its own unwind information, as **the JIT runtime might be configured to register the information in a way that is compatible with libgcc_s but not libunwind. **

Potential Solutions
Link with libgcc_s: The most straightforward solution in many cases is to use the GNU unwinder instead of LLVM's libunwind. You can often achieve this by adding the linker flag --unwindlib=libgcc. This links your application against libgcc_s, which is compatible with the format of the provided unwind information.
Modify Build Configuration:
Build libunwind with NDEBUG: Some users on the LLVM GitHub issues found that building the llvm-libunwind package with the -DNDEBUG flag resolved the warning, effectively disabling the assertion that causes the message.
Use ORCv2 Runtime: If you are using JIT, switching to the newer LLVM ORCv2 platform and runtime might provide a fix, as it includes specific handling for this scenario.
Use compatible C++ standard library: The issue is often seen when linking with libc++ but may disappear when linking with libstdc++.
Update LLVM/Clang: Ensure you are using a recent version of the LLVM toolchain, as fixes for this interaction have been implemented in newer releases.

[yfinkelstein]

We can close the issue but perhaps mention this somewhere in the docs ?