[EH] Add __cxa_init_primary_exception to cxa_noexception.cpp #22027

aheejin · 2024-05-31T08:10:49Z

tl;dr:

This adds __cxa_init_primary_exception to cxa_noexception.cpp.

Other targets build cxa_exception.cpp in -fignore-exceptions mode and build cxa_noexception.cpp only in -fno-exeptions mode. But we build cxa_noexception.cpp in -fignore-exceptions mode, which means it needs the definition for __cxa_init_primary_exception for linking to succeed when no EH argument is given (which means -fignore-exceptions).

Long version (Feel free to skip):

Background:

After #21638, __cxa_init_primary_exception was added in libcxxabi:

emscripten/system/lib/libcxxabi/src/cxa_exception.cpp

Lines 209 to 226 in 28c10a1

    
           __cxa_exception* __cxa_init_primary_exception(void* object, std::type_info* tinfo, 
        
           #ifdef __wasm__ 
        
           // In Wasm, a destructor returns its argument 
        
                                                         void *(_LIBCXXABI_DTOR_FUNC* dest)(void*)) throw() { 
        
           #else 
        
                                                         void(_LIBCXXABI_DTOR_FUNC* dest)(void*)) throw() { 
        
           #endif 
        
             __cxa_exception* exception_header = cxa_exception_from_thrown_object(object); 
        
             exception_header->referenceCount = 0; 
        
             exception_header->unexpectedHandler = std::get_unexpected(); 
        
             exception_header->terminateHandler = std::get_terminate(); 
        
             exception_header->exceptionType = tinfo; 
        
             exception_header->exceptionDestructor = dest; 
        
             setOurExceptionClass(&exception_header->unwindHeader); 
        
             exception_header->unwindHeader.exception_cleanup = exception_cleanup_func; 
        
             return exception_header; 
        
           }

emscripten/system/lib/libcxxabi/src/cxa_exception_emscripten.cpp

Lines 155 to 162 in 28c10a1

    
           __cxa_exception* __cxa_init_primary_exception(void* object, std::type_info* tinfo, 
        
                                                         void *(_LIBCXXABI_DTOR_FUNC* dest)(void*)) throw() { 
        
             __cxa_exception* exception_header = cxa_exception_from_thrown_object(object); 
        
             exception_header->referenceCount = 0; 
        
             exception_header->exceptionType = tinfo; 
        
             exception_header->exceptionDestructor = dest; 
        
             return exception_header; 
        
           }

Currently the files containing __cxa_init_primary_exception, cxa_exception.cpp and cxa_exception_emscripten.cpp, are only compiled when any of the EH mode is specified. cxa_exception.cpp is compiled when Wasm EH is selected, and cxa_exception_emscripten.cpp is compiled when Emscripten EH is selected:

emscripten/tools/system_libs.py

Lines 1599 to 1608 in 28c10a1

    
           if self.eh_mode == Exceptions.NONE: 
        
             filenames += ['cxa_noexception.cpp'] 
        
           elif self.eh_mode == Exceptions.EMSCRIPTEN: 
        
             filenames += ['cxa_exception_emscripten.cpp'] 
        
           elif self.eh_mode == Exceptions.WASM: 
        
             filenames += [ 
        
               'cxa_exception_storage.cpp', 
        
               'cxa_exception.cpp', 
        
               'cxa_personality.cpp' 
        
             ]

and this function is called from make_exception_ptr in libcxx:

emscripten/system/lib/libcxx/include/__exception/exception_ptr.h

Lines 87 to 99 in 28c10a1

    
           template <class _Ep> 
        
           _LIBCPP_HIDE_FROM_ABI exception_ptr make_exception_ptr(_Ep __e) _NOEXCEPT { 
        
           #  ifndef _LIBCPP_HAS_NO_EXCEPTIONS 
        
           #    if _LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION && __cplusplus >= 201103L 
        
             using _Ep2 = __decay_t<_Ep>; 
        
             void* __ex = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ep)); 
        
           #      ifdef __wasm__ 
        
             // In Wasm, a destructor returns its argument 
        
             (void)__cxxabiv1::__cxa_init_primary_exception(__ex, const_cast<std::type_info*>(&typeid(_Ep)), [](void* __p) -> void* { 
        
           #      else 
        
             (void)__cxxabiv1::__cxa_init_primary_exception(__ex, const_cast<std::type_info*>(&typeid(_Ep)), [](void* __p) { 
        
           #      endif

And make_exception_ptr is called from std::promise's destructor:

emscripten/system/lib/libcxx/include/future

Lines 1161 to 1168 in 28c10a1

    
           template <class _Rp> 
        
           promise<_Rp>::~promise() { 
        
             if (__state_) { 
        
               if (!__state_->__has_value() && __state_->use_count() > 1) 
        
                 __state_->set_exception(make_exception_ptr(future_error(make_error_code(future_errc::broken_promise)))); 
        
               __state_->__release_shared(); 
        
             } 
        
           }

Bug:

Currently any program that calls std::promise's destructor without specifying any exception-related arguments fails, saying undefined symbol: __cxa_init_primary_exception. Not specifying any exception arguments, meaning not specifying any among -fno-exceptions, -fwasm-exceptions, -fexceptions, or
-sDISABLE_EXCEPTION_CATCHING=0, defaults to -fignore-exceptions, which allows throwing but not catching.

Analysis:

The callsite of __cxa_init_primary_exception in make_exception_ptr is guarded with #ifndef _LIBCPP_HAS_NO_EXCEPTIONS, so it seems it is supposed to be included only when exceptions are enabled. This _LIBCPP_HAS_NO_EXCEPTIONS is defined when __cpp_exceptions is defined:

emscripten/system/lib/libcxx/include/__config

Lines 644 to 646 in 28c10a1

    
           #  if !defined(__cpp_exceptions) || __cpp_exceptions < 199711L 
        
           #    define _LIBCPP_HAS_NO_EXCEPTIONS 
        
           #  endif

And that __cpp_exceptions is defined in clang, when -fcxx-exceptions is given:
https://github.com/llvm/llvm-project/blob/be566d2eacdaed972b90d2eeb1e66d732c9fe7c1/clang/lib/Frontend/InitPreprocessor.cpp#L638-L639

And that -fcxx-exceptions can be specified in command line, but it is also programmatically added here:
https://github.com/llvm/llvm-project/blob/be566d2eacdaed972b90d2eeb1e66d732c9fe7c1/clang/lib/Driver/ToolChains/Clang.cpp#L371-L388

You can see it is added by default unless the arch is XCore or PS4/PS5, which means for Wasm it has been always added so far, unless -fno-exceptions is explicitly specified.

So I tried checking the arguments there in Clang and adding -fcxx-exceptions only if either of -fwasm-exceptions or -enable-emscripten-cxx-exceptions is given. But this fails when none of EH is selected (which means -fignore-exceptions), because if -fcxx-exceptions is not added, we can't use keywords like throw.

So basically the problem is, other targets build cxa_exception.cpp in -fignore-exceptions mode and build cxa_noexception.cpp only in -fno-exeptions mode. But we build cxa_noexception.cpp in -fignore-exceptions mode, which means it needs the definition for __cxa_init_primary_exception for linking to succeed, because _LIBCPP_HAS_NO_EXCEPTIONS cannot be defined in -fignore-exceptions (because we couldn't disable -fcxx-exceptions above in Clang to use throw)

So this adds __cxa_init_primary_exception to cxa_noexception.cpp.

tl;dr: This adds `__cxa_init_primary_exception` to `cxa_noexception.cpp`. Other targets build `cxa_exception.cpp` in `-fignore-exceptions` mode and build `cxa_noexception.cpp` only in `-fno-exeptions` mode. But we build `cxa_noexception.cpp` in `-fignore-exceptions` mode, which means it needs the definition for `__cxa_init_primary_exception` for linking to succeed when no EH argument is given (which means `-fignore-exceptions`). --- Long version (Feel free to skip): Background: After emscripten-core#21638, `__cxa_init_primary_exception` was added in libcxxabi: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxxabi/src/cxa_exception.cpp#L209-L226 https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxxabi/src/cxa_exception_emscripten.cpp#L155-L162 Currently the files containing `__cxa_init_primary_exception`, `cxa_exception.cpp` and `cxa_exception_emscripten.cpp`, are only compiled when any of the EH mode is specified. `cxa_exception.cpp` is compiled when Wasm EH is selected, and `cxa_exception_emscripten.cpp` is compiled when Emscripten EH is selected: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/tools/system_libs.py#L1599-L1608 and this function is called from `make_exception_ptr` in libcxx: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxx/include/__exception/exception_ptr.h#L87-L99 And `make_exception_ptr` is called from `std::promise`'s destructor: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxx/include/future#L1161-L1168 --- Bug: Currently any program that calls `std::promise`'s destructor without specifying any exception-related arguments fails, saying `undefined symbol: __cxa_init_primary_exception`. Not specifying any exception arguments, meaning not specifying any among `-fno-exceptions`, `-fwasm-exceptions`, `-fexceptions`, or `-sDISABLE_EXCEPTION_CATCHING=0`, defaults to `-fignore-exceptions`, which allows throwing but not catching. --- Analysis: The callsite of `__cxa_init_primary_exception` in `make_exception_ptr` is guarded with `#ifndef _LIBCPP_HAS_NO_EXCEPTIONS`, so it seems it is supposed to be included only when exceptions are enabled. This `_LIBCPP_HAS_NO_EXCEPTIONS` is defined when `__cpp_exceptions` is defined: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxx/include/__config#L644-L646 And that `__cpp_exceptions` is defined in clang, when `-fcxx-exceptions` is given: https://github.com/llvm/llvm-project/blob/be566d2eacdaed972b90d2eeb1e66d732c9fe7c1/clang/lib/Frontend/InitPreprocessor.cpp#L638-L639 And that `-fcxx-exceptions` can be specified in command line, but it is also programmatically added here: https://github.com/llvm/llvm-project/blob/be566d2eacdaed972b90d2eeb1e66d732c9fe7c1/clang/lib/Driver/ToolChains/Clang.cpp#L371-L388 You can see it is added by default unless the arch is XCore or PS4/PS5, which means for Wasm it has been always added so far, unless `-fno-exceptions` is explicitly specified. So I tried checking the arguments there in Clang and adding `-fcxx-exceptions` only if either of `-fwasm-exceptions` or `-enable-emscripten-cxx-exceptions` is given. But this fails when none of EH is selected (which means `-fignore-exceptions`), because if `-fcxx-exceptions` is not added, we can't use keywords like `throw`. So basically the problem is, other targets build `cxa_exception.cpp` in `-fignore-exceptions` mode and build `cxa_noexception.cpp` only in `-fno-exeptions` mode. But we build `cxa_noexception.cpp` in `-fignore-exceptions` mode, which means it needs the definition for `__cxa_init_primary_exception` for linking to succeed, because `_LIBCPP_HAS_NO_EXCEPTIONS` cannot be defined in `-fignore-exceptions` (because we couldn't disable `-fcxx-exceptions` above in Clang to use `throw`) So this adds `__cxa_init_primary_exception` to `cxa_noexception.cpp`.

sbc100

I assume this change is probably suitable for upstreaming?

aheejin · 2024-05-31T08:34:59Z

Not sure. I've been upstreaming the changes that are likely necessary for upstream CMake users, and unless they use our system_libs.py, this is not gonna be necessary.

Also, cxa_noexceptions.cpp contains other emscripten-only functions too. Do you think we should upstream all these?

emscripten/system/lib/libcxxabi/src/cxa_noexception.cpp

Lines 52 to 77 in 28c10a1

    
           #if __EMSCRIPTEN__ 
        
           // Under emscripten this code is also linked when building when 
        
           // DISABLE_EXCEPTION_CATCHING is set but DISABLE_EXCEPTION_THROWING is not. 
        
           // TODO(sbc): Perhaps just call std::terminate here. It could 
        
           // just be some test code that needs updating. 
        
           void *__cxa_allocate_exception(size_t thrown_size) throw() { 
        
             char* allocation = (char*)malloc(thrown_size + sizeof(__cxa_exception)); 
        
             return allocation + sizeof(__cxa_exception); 
        
           } 
        
           static 
        
           inline 
        
           __cxa_exception* 
        
           cxa_exception_from_thrown_object(void* thrown_object) 
        
           { 
        
               return static_cast<__cxa_exception*>(thrown_object) - 1; 
        
           } 
        
           //  Free a __cxa_exception object allocated with __cxa_allocate_exception. 
        
           void __cxa_free_exception(void *thrown_object) throw() { 
        
               // Compute the size of the padding before the header. 
        
               char *raw_buffer = 
        
                   ((char *)cxa_exception_from_thrown_object(thrown_object)); 
        
               free((void *)raw_buffer); 
        
           } 
        
           #endif

mzukovec · 2024-05-31T11:00:32Z

Thanks for looking into this!

sbc100 · 2024-05-31T16:13:49Z

Not sure. I've been upstreaming the changes that are likely necessary for upstream CMake users, and unless they use our system_libs.py, this is not gonna be necessary.

Also, cxa_noexceptions.cpp contains other emscripten-only functions too. Do you think we should upstream all these?

emscripten/system/lib/libcxxabi/src/cxa_noexception.cpp

Lines 52 to 77 in 28c10a1

#if __EMSCRIPTEN__

// Under emscripten this code is also linked when building when

// DISABLE_EXCEPTION_CATCHING is set but DISABLE_EXCEPTION_THROWING is not.

// TODO(sbc): Perhaps just call std::terminate here. It could

// just be some test code that needs updating.

void *__cxa_allocate_exception(size_t thrown_size) throw() {

char* allocation = (char*)malloc(thrown_size + sizeof(__cxa_exception));

return allocation + sizeof(__cxa_exception);

}

static

inline

__cxa_exception*

cxa_exception_from_thrown_object(void* thrown_object)

{

return static_cast<__cxa_exception*>(thrown_object) - 1;

}

// Free a __cxa_exception object allocated with __cxa_allocate_exception.

void __cxa_free_exception(void *thrown_object) throw() {

// Compute the size of the padding before the header.

char *raw_buffer =

((char *)cxa_exception_from_thrown_object(thrown_object));

free((void *)raw_buffer);

}

#endif

I guess my question is, is this __cxa_init_primary_exception (or the need for it) emscripten-specific? How come calls to it are being generated by the wasm backend but not other backends?

aheejin · 2024-05-31T17:35:04Z

I guess my question is, is this __cxa_init_primary_exception (or the need for it) emscripten-specific? How come calls to it are being generated by the wasm backend but not other backends?

Calls to __cxa_init_primary_exception are generated in other backends too. But they use cxa_exceptions.cpp in case of -fignore-exceptions so it's not a problem. They use cxa_noexceptions.cpp only when -fno-exceptions is given, in which case _LIBCPP_HAS_NO_EXCEPTIONS is defined and the calls to __cxa_init_primary_exception are not compiled:

emscripten/system/lib/libcxx/include/__exception/exception_ptr.h

Lines 87 to 99 in 28c10a1

    
           template <class _Ep> 
        
           _LIBCPP_HIDE_FROM_ABI exception_ptr make_exception_ptr(_Ep __e) _NOEXCEPT { 
        
           #  ifndef _LIBCPP_HAS_NO_EXCEPTIONS 
        
           #    if _LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION && __cplusplus >= 201103L 
        
             using _Ep2 = __decay_t<_Ep>; 
        
             void* __ex = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ep)); 
        
           #      ifdef __wasm__ 
        
             // In Wasm, a destructor returns its argument 
        
             (void)__cxxabiv1::__cxa_init_primary_exception(__ex, const_cast<std::type_info*>(&typeid(_Ep)), [](void* __p) -> void* { 
        
           #      else 
        
             (void)__cxxabiv1::__cxa_init_primary_exception(__ex, const_cast<std::type_info*>(&typeid(_Ep)), [](void* __p) { 
        
           #      endif

But we use cxa_noexception.cpp in case of -fignore-exceptions, which is our default. That's why I added the function there.

sbc100 · 2024-05-31T17:44:06Z

I guess my question is, is this __cxa_init_primary_exception (or the need for it) emscripten-specific? How come calls to it are being generated by the wasm backend but not other backends?

Calls to __cxa_init_primary_exception are generated in other backends too. But they use cxa_exceptions.cpp in case of -fignore-exceptions so it's not a problem. They use cxa_noexceptions.cpp only when -fno-exceptions is given, in which case _LIBCPP_HAS_NO_EXCEPTIONS is defined and the calls to __cxa_init_primary_exception is not compiled:

emscripten/system/lib/libcxx/include/__exception/exception_ptr.h

Lines 87 to 99 in 28c10a1

template <class _Ep>

_LIBCPP_HIDE_FROM_ABI exception_ptr make_exception_ptr(_Ep __e) _NOEXCEPT {

# ifndef _LIBCPP_HAS_NO_EXCEPTIONS

# if _LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION && __cplusplus >= 201103L

using _Ep2 = __decay_t<_Ep>;

void* __ex = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ep));

# ifdef __wasm__

// In Wasm, a destructor returns its argument

(void)__cxxabiv1::__cxa_init_primary_exception(__ex, const_cast<std::type_info*>(&typeid(_Ep)), [](void* __p) -> void* {

# else

(void)__cxxabiv1::__cxa_init_primary_exception(__ex, const_cast<std::type_info*>(&typeid(_Ep)), [](void* __p) {

# endif

But we use cxa_noexception.cpp in case of -fignore-exceptions, which is our default. That's why I added the function there.

I see.. so the issue stems from the different/special way that we handle -fignore-exceptions. Might be worth adding a comment here to that effect.

aheejin · 2024-05-31T17:56:13Z

I see.. so the issue stems from the different/special way that we handle -fignore-exceptions. Might be worth adding a comment here to that effect.

#22034

…ten-core#22027) tl;dr: This adds `__cxa_init_primary_exception` to `cxa_noexception.cpp`. Other targets build `cxa_exception.cpp` in `-fignore-exceptions` mode and build `cxa_noexception.cpp` only in `-fno-exeptions` mode. But we build `cxa_noexception.cpp` in `-fignore-exceptions` mode, which means it needs the definition for `__cxa_init_primary_exception` for linking to succeed when no EH argument is given (which means `-fignore-exceptions`). --- Long version (Feel free to skip): Background: After emscripten-core#21638, `__cxa_init_primary_exception` was added in libcxxabi: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxxabi/src/cxa_exception.cpp#L209-L226 https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxxabi/src/cxa_exception_emscripten.cpp#L155-L162 Currently the files containing `__cxa_init_primary_exception`, `cxa_exception.cpp` and `cxa_exception_emscripten.cpp`, are only compiled when any of the EH mode is specified. `cxa_exception.cpp` is compiled when Wasm EH is selected, and `cxa_exception_emscripten.cpp` is compiled when Emscripten EH is selected: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/tools/system_libs.py#L1599-L1608 and this function is called from `make_exception_ptr` in libcxx: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxx/include/__exception/exception_ptr.h#L87-L99 And `make_exception_ptr` is called from `std::promise`'s destructor: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxx/include/future#L1161-L1168 --- Bug: Currently any program that calls `std::promise`'s destructor without specifying any exception-related arguments fails, saying `undefined symbol: __cxa_init_primary_exception`. Not specifying any exception arguments, meaning not specifying any among `-fno-exceptions`, `-fwasm-exceptions`, `-fexceptions`, or `-sDISABLE_EXCEPTION_CATCHING=0`, defaults to `-fignore-exceptions`, which allows throwing but not catching. --- Analysis: The callsite of `__cxa_init_primary_exception` in `make_exception_ptr` is guarded with `#ifndef _LIBCPP_HAS_NO_EXCEPTIONS`, so it seems it is supposed to be included only when exceptions are enabled. This `_LIBCPP_HAS_NO_EXCEPTIONS` is defined when `__cpp_exceptions` is defined: https://github.com/emscripten-core/emscripten/blob/28c10a1c5e2862edadd68ab627478204ae96d134/system/lib/libcxx/include/__config#L644-L646 And that `__cpp_exceptions` is defined in clang, when `-fcxx-exceptions` is given: https://github.com/llvm/llvm-project/blob/be566d2eacdaed972b90d2eeb1e66d732c9fe7c1/clang/lib/Frontend/InitPreprocessor.cpp#L638-L639 And that `-fcxx-exceptions` can be specified in command line, but it is also programmatically added here: https://github.com/llvm/llvm-project/blob/be566d2eacdaed972b90d2eeb1e66d732c9fe7c1/clang/lib/Driver/ToolChains/Clang.cpp#L371-L388 You can see it is added by default unless the arch is XCore or PS4/PS5, which means for Wasm it has been always added so far, unless `-fno-exceptions` is explicitly specified. So I tried checking the arguments there in Clang and adding `-fcxx-exceptions` only if either of `-fwasm-exceptions` or `-enable-emscripten-cxx-exceptions` is given. But this fails when none of EH is selected (which means `-fignore-exceptions`), because if `-fcxx-exceptions` is not added, we can't use keywords like `throw`. So basically the problem is, other targets build `cxa_exception.cpp` in `-fignore-exceptions` mode and build `cxa_noexception.cpp` only in `-fno-exeptions` mode. But we build `cxa_noexception.cpp` in `-fignore-exceptions` mode, which means it needs the definition for `__cxa_init_primary_exception` for linking to succeed, because `_LIBCPP_HAS_NO_EXCEPTIONS` cannot be defined in `-fignore-exceptions` (because we couldn't disable `-fcxx-exceptions` above in Clang to use `throw`) So this adds `__cxa_init_primary_exception` to `cxa_noexception.cpp`.

aheejin requested a review from sbc100 May 31, 2024 08:10

aheejin mentioned this pull request May 31, 2024

Update libcxx and libcxxabi to LLVM 18.1.2 #21638

Merged

aheejin added 3 commits May 31, 2024 08:14

Merge branch 'main' into init_primary_ex

ed40975

test name change

ca096fb

comment fix

350d7d1

sbc100 approved these changes May 31, 2024

View reviewed changes

dschuff approved these changes May 31, 2024

View reviewed changes

aheejin merged commit b0ec4e1 into emscripten-core:main May 31, 2024
29 checks passed

aheejin deleted the init_primary_ex branch May 31, 2024 16:14

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[EH] Add __cxa_init_primary_exception to cxa_noexception.cpp #22027

[EH] Add __cxa_init_primary_exception to cxa_noexception.cpp #22027

aheejin commented May 31, 2024 •

edited

Loading

sbc100 left a comment

aheejin commented May 31, 2024

mzukovec commented May 31, 2024

sbc100 commented May 31, 2024

aheejin commented May 31, 2024 •

edited

Loading

sbc100 commented May 31, 2024

aheejin commented May 31, 2024

	__cxa_exception* __cxa_init_primary_exception(void* object, std::type_info* tinfo,
	#ifdef __wasm__
	// In Wasm, a destructor returns its argument
	void (_LIBCXXABI_DTOR_FUNC dest)(void*)) throw() {
	#else
	void(_LIBCXXABI_DTOR_FUNC* dest)(void*)) throw() {
	#endif
	__cxa_exception* exception_header = cxa_exception_from_thrown_object(object);
	exception_header->referenceCount = 0;
	exception_header->unexpectedHandler = std::get_unexpected();
	exception_header->terminateHandler = std::get_terminate();
	exception_header->exceptionType = tinfo;
	exception_header->exceptionDestructor = dest;
	setOurExceptionClass(&exception_header->unwindHeader);
	exception_header->unwindHeader.exception_cleanup = exception_cleanup_func;

	return exception_header;
	}

	if self.eh_mode == Exceptions.NONE:
	filenames += ['cxa_noexception.cpp']
	elif self.eh_mode == Exceptions.EMSCRIPTEN:
	filenames += ['cxa_exception_emscripten.cpp']
	elif self.eh_mode == Exceptions.WASM:
	filenames += [
	'cxa_exception_storage.cpp',
	'cxa_exception.cpp',
	'cxa_personality.cpp'
	]

	template <class _Ep>
	_LIBCPP_HIDE_FROM_ABI exception_ptr make_exception_ptr(_Ep __e) _NOEXCEPT {
	# ifndef _LIBCPP_HAS_NO_EXCEPTIONS
	# if _LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION && __cplusplus >= 201103L
	using _Ep2 = __decay_t<_Ep>;

	void* __ex = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ep));
	# ifdef __wasm__
	// In Wasm, a destructor returns its argument
	(void)__cxxabiv1::__cxa_init_primary_exception(__ex, const_cast<std::type_info>(&typeid(_Ep)), [](void __p) -> void* {
	# else
	(void)__cxxabiv1::__cxa_init_primary_exception(__ex, const_cast<std::type_info>(&typeid(_Ep)), [](void __p) {
	# endif

	template <class _Rp>
	promise<_Rp>::~promise() {
	if (__state_) {
	if (!__state_->__has_value() && __state_->use_count() > 1)
	__state_->set_exception(make_exception_ptr(future_error(make_error_code(future_errc::broken_promise))));
	__state_->__release_shared();
	}
	}

	# if !defined(__cpp_exceptions) \|\| __cpp_exceptions < 199711L
	# define _LIBCPP_HAS_NO_EXCEPTIONS
	# endif

[EH] Add __cxa_init_primary_exception to cxa_noexception.cpp #22027

[EH] Add __cxa_init_primary_exception to cxa_noexception.cpp #22027

Conversation

aheejin commented May 31, 2024 • edited Loading

sbc100 left a comment

Choose a reason for hiding this comment

aheejin commented May 31, 2024

mzukovec commented May 31, 2024

sbc100 commented May 31, 2024

aheejin commented May 31, 2024 • edited Loading

sbc100 commented May 31, 2024

aheejin commented May 31, 2024

aheejin commented May 31, 2024 •

edited

Loading

aheejin commented May 31, 2024 •

edited

Loading