Update libcxx and libcxxabi from LLVM 21.1.8 to 22.1.8

[aheejin]

This updates libcxx and libcxxabi from 21.1.8 to LLVM 22.1.8:
https://github.com/llvm/llvm-project/releases/tag/llvmorg-22.1.8

Additional changes:
(More detailed descriptions are in the commit messages)

• Don't copy llvm-libc files in update_libcxx.py: e7af49c, e81407b
  In update_libcxx.py, we don't copy llvm-libc files that libcxx depend on anymore, because we copy those files in update_llvm_libc.py too. We just assume llvm-libc has been updated to the same version before doing update, and I wrote that in the comments.

• Define _LIBCPP_ASSERTION_SEMANTIC_DEFAULT in __config_site: b119c87
  [libc++][hardening] Allow setting the assertion semantic via CMake. llvm/llvm-project#167636 forces us to define _LIBCPP_ASSERTION_SEMANTIC_DEFAULT. This defines it to follow the hardening mode.

• Undefine _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE: e9f7296
  After [libc++] Always define _LIBCPP_GLIBC_PREREQ llvm/llvm-project#169405, _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE was defined, which caused Emscripten to use copy_file_range. This commit adds !defined(__EMSCRIPTEN__) clause at the end to make _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE undefined for Emscripten, as was before this update.

• Make __cxa_thread_atexit available for Emscripten: 638d0e1
  [libc++] Enable -Wmissing-prototypes llvm/llvm-project#116261 wrapped __cxa_thread_atexit with #if defined(__linux__) || defined(__Fuchsia__), which caused it to be undefined in Emscripten. This adds defined(__EMSCRIPTEN__) to make it available again.

• Increase size expectations of test_malloc_size*: c818aa2
  This increase seems to be mainly due to the changes of implementation of std::num_get in libcxx/include/__locale_dir/num.h in [libc++] Optimize num_get integral functions llvm/llvm-project#121795. Note that we had a similar size increase due to changes in std::num_put in Reapply "[libc++] Optimize num_put integral functions" (#131613) llvm/llvm-project#133572 in LLVM 21 update (Update libcxx and libcxxabi from LLVM 20.1.8 to 21.1.8 #26058).

• Create module.modulemap from module.modulemap.in: be1f0a7
  libcxx used to have module.modulemap, but since LLVM 21, it was changed to module.modulemap.in in [libc++] Make __config_site modular llvm/llvm-project#134699. Rather than we copy this manually in each update, this makes update_libcxx.py create module.modulemap from module.modulemap.in automaticaly.

• Copy default_assertion_handler.in to __assertion_handler: 547432f
  Since LLVM 18, [libc++][hardening] Rework how the assertion handler can be overridden. llvm/llvm-project#77883 started to provide a default assertion handler and a way to override it. We have been using the default handler ever since. Rather than manually copying it in each release, this automates the copying of the file in update_libcxx.py.

[sbc100]

Can we not find a way to instead have libc++ not compile in the call to this function? Presumably its not just assuming it exists on all platforms?

[aheejin]

Why is it preferable not to compile this file?

[sbc100]

Not calling a function at all is always better than calling a stub version isn't it? Doesn't libc++ allow for this linux-specific thing to not exist?

[aheejin]

Which one do you prefer?

Solution 1: Add it to emscripten_libs_stub.c

diff --git a/system/lib/libc/emscripten_libc_stubs.c b/system/lib/libc/emscripten_libc_stubs.c
index bd0759bd6..2cccdd9a0 100644
--- a/system/lib/libc/emscripten_libc_stubs.c
+++ b/system/lib/libc/emscripten_libc_stubs.c
@@ -255,3 +255,12 @@ weak int getloadavg(double loadavg[], int nelem) {
   }
   return limit;
 }
+
+// ==========================================================================
+// unistd.h
+// ==========================================================================
+
+weak ssize_t copy_file_range(int fd_in, off_t *off_in, int fd_out, off_t *off_out, size_t len, unsigned flags) {
+  errno = ENOSYS;
+  return -1;
+}

Solution 2: Add if !defined(__EMSCRIPTEN__) directly into source code where _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE is defined

diff --git a/system/lib/libcxx/src/filesystem/operations.cpp b/system/lib/libcxx/src/filesystem/operations.cpp
index 745db87ce..4c6853fc4 100644
--- a/system/lib/libcxx/src/filesystem/operations.cpp
+++ b/system/lib/libcxx/src/filesystem/operations.cpp
@@ -41,7 +41,7 @@
 #include <time.h>
 
 // since Linux 4.5 and FreeBSD 13, but the Linux libc wrapper is only provided by glibc >= 2.27 and musl
-#if _LIBCPP_GLIBC_PREREQ(2, 27) || _LIBCPP_HAS_MUSL_LIBC || defined(__FreeBSD__)
+#if (_LIBCPP_GLIBC_PREREQ(2, 27) || _LIBCPP_HAS_MUSL_LIBC || defined(__FreeBSD__)) && !defined(__EMSCRIPTEN__)
 #  define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE
 #endif
 

[sbc100]

Yes, not defining _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE seems better.

That solution seems good as you have it, but I also wonder if we should consider not defining _LIBCPP_HAS_MUSL_LIBC too? I guess that could have other knock on effects.

[aheejin]

But we have musl libc. Why undefine it?

Anyway I tried to undefine it (both removing the line below and changing it to 0) and now we have endless number of undeclared identifier errors.

emscripten/system/lib/libcxx/include/__config_site

Line 9 in f11cc0b

#define _LIBCPP_HAS_MUSL_LIBC 1

This was first added in #24346 (LLVM 20 update) and I chose 1 because it was already defined (See 9912236)

[sbc100]

Yup, probably not worth it.

I was just thinking it might help in cases like this where _LIBCPP_HAS_MUSL_LIBC implies linux-specific stuff (since musl is normally considered linux-only).

In any case I think your proposed solution of of add !__EMSCRIPTEN__ to the _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE definition seem good.

[aheejin]

Applied solution 2: e9f7296