Define wasm-eh tags in native code. NFC

[sbc100]

These tags have also historically be weakly defined in each object file by llvm (at least for non-PIC object files) but I hope to remove those definitions going forward and instead rely on the toolchain/compiler-rt to define them.

This will remove one of the distinctions between PIC and non-PIC generated code.

This change can land here on the emscripten side before the corresponding llvm changes since the strong definition I'm adding here will always take precedence over any weak definitions in object files.

See llvm/llvm-project#159143

[aheejin]

I think this was necessary to make dynamic linking work... What changed? Where do we define these now?

[sbc100]

I think this was necessary to make dynamic linking work... What changed? Where do we define these now?

Today we have two different modes:

1. Dynamic linking (PIC). In this mode each object file declares these tags as imports and expects them to be provided by the runtime. In this case we define them in JS.
2. Static linking (non-PIC). Each object file contains its own weak definition and the linker just chooses one.

One the of the reasons for this change is to unify these two modes into one mode that just works everywhere. In the new mode:

• tags are expected to be defined by compiler-rt or libc (or anyone really) at link time.
• tags are never defined automatically in object files
• shared libraries don't define tags but import them from the main module (libc/runtime module) which contains the single definition.

[sbc100]

This change can land here on the emscripten side before the corresponding llvm changes since the strong definition I'm adding here will always take precedence over any weak definitions in object files.

[dschuff]

I think it maybe makes more sense to define __cpp_exception in libc++abi. IIRC that's where we define the functions that the compiler emits calls to such as __cxa_throw.
Slightly annoying that we'd be separating __cpp_exception from __c_longjmp but I think its' the right layering.
Speaking of which, where does __c_longjmp belong? Do we define longjmp in compiler-rt or libc?

[aheejin]

We define longjmp-related functions here: https://github.com/emscripten-core/emscripten/blob/main/system/lib/compiler-rt/emscripten_setjmp.c
Also a bit of Emscripten EH related stuff: https://github.com/emscripten-core/emscripten/blob/main/system/lib/compiler-rt/emscripten_exception_builtins.c

[dschuff]

Is the latter file in compiler-rt because setThrew is shared between EH and SJLJ?

[aheejin]

Ah right, setThrew is also used in Emscripten SjLj. Yeah I think that's the reason.

[sbc100]

I move the definitions into their own files. And I moved __cpp_exception to libcxxabi

[aheejin]

Where are we putting tag symbols, libcxxabi or compiler-rt? llvm/llvm-project#159143 puts both in compiler-rt but this puts __cpp_exceptions in libc++abi, so..

Personally I think putting both in compiler-rt is fine, given that these are things we never get to upstream to the upstream libc++abi anyway.

[sbc100]

I agree we should match llvm/llvm-project#159143 once it lands.