On systems using glibc there are apparently some ways libgcc_s is dynamically
loaded during backtrace or stack unwinding.
libunwind and libgcc_s then have conflicting definitions, which typically leads to a seqfault.

The issue is discussed at https://reviews.llvm.org/D106703, I also made an issue at
https://github.com/llvm/llvm-project/issues/90041.

Tough it seems specific to debian, and as far as I understand you should not
use libunwind with glibc as libgcc_s will be always mixed in.
In a distro based on glibc, libunwind should probably not be used at all,
removing it from libc++abi1 should atleast make libc++ work.


Simple example:
------
#include <pthread.h>
#include <thread>
extern "C" int main()
{
    std::thread systhr([]() { std::this_thread::sleep_for(std::chrono::seconds(10000)); });

    std::this_thread::sleep_for(std::chrono::seconds(1));
    pthread_cancel(systhr.native_handle());

    systhr.join();
    return 0;
}
------

Compile the code with either unwind library:

clang++ -stdlib=libc++ test.cpp
clang++ -stdlib=libc++ -unwindlib=libunwind --rtlib=compiler-rt -O2 test.cpp

Running the program will crash, as libgcc's unwinder will *always* be used:

------
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7e51cb4 in __unw_get_proc_info () at build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libunwind/src/libunwind.cpp:201
#2  0x00007ffff7e571e6 in _Unwind_GetLanguageSpecificData () at build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libunwind/src/UnwindLevel1.c:528
#3  0x00007ffff7e89415 in scan_eh_tab () at build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libcxxabi/src/cxa_personality.cpp:626
#4  __gxx_personality_v0 () at build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libcxxabi/src/cxa_personality.cpp:957
#5  0x00007ffff735a860 in _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0x7ffff7b65d30, context=context@entry=0x7ffff7b64ce0, frames_p=frames_p@entry=0x7ffff7b64be8) at ../../../src/libgcc/unwind.inc:183
#6  0x00007ffff735af40 in _Unwind_ForcedUnwind (exc=0x7ffff7b65d30, stop=0x7ffff7c04f30 <unwind_stop>, stop_argument=<optimized out>) at ../../../src/libgcc/unwind.inc:218
#7  0x00007ffff7c050b0 in __GI___pthread_unwind (buf=<optimized out>) at ./nptl/unwind.c:130
#8  0x00007ffff7bf9613 in __do_cancel (result=0xffffffffffffffff) at ../sysdeps/nptl/pthreadP.h:273
#9  __syscall_do_cancel () at ./nptl/cancellation.c:109
#10 0x00007ffff7bf969d in __internal_syscall_cancel (a1=a1@entry=0, a2=a2@entry=0, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=0, a6=a6@entry=0, nr=230) at ./nptl/cancellation.c:61
#11 0x00007ffff7c45f7a in __GI___clock_nanosleep (clock_id=<optimized out>, clock_id@entry=0, flags=flags@entry=0, req=<optimized out>, rem=<optimized out>) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
#12 0x00007ffff7c51393 in __GI___nanosleep (req=<optimized out>, rem=<optimized out>) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#13 0x00007ffff7effceb in __libcpp_thread_sleep_for () at build-llvm/tools/clang/stage2-bins/include/c++/v1/__thread/support/pthread.h:198
#14 sleep_for () at build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/libcxx/src/thread.cpp:94
#15 0x000055555555530e in void* std::__1::__thread_proxy[abi:ne190107]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, main::$_0> >(void*) ()
#16 0x00007ffff7bfcb7b in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448
#17 0x00007ffff7c7a7b8 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
------


This is also a duplicate of #1071210, but I guess Bugs for llvm-toolchain-18
receive no attention.