[loongarch64] integration_test libc-integration.c fails with signal 11 (SIGSEGV) on loongarch64

[wszqkzqk]

Description

When building wild 0.8.0 on loongarch64, the test suite fails with a segmentation fault (signal 11) in the libc integration test.

Test Result: 97 passed; 1 failed; 0 ignored

Error Details

failures:  

---- integration_test::program_name_53___libc_integration_c__ stdout ----
Error: Failed to run program. Binary /build/wild/src/wild-0.8.0/wild/tests/build/libc-integration.c/libc-integration.c-clang-static-host.lld. Relink with:
        clang --ld-path=/usr/bin/ld.lld -static -Wl,--strip-debug -Wl,--gc-sections -Wl,-z,now -o /build/wild/src/wild-0.8.0/wild/tests/build/libc-integration.c/libc-integration.c-clang-static-host.lld /build/wild/src/wild-0.8.0/wild/tests/build/libc-integration.c/libc-integration.clang-static-host-d4bb7b374388ac2c.o /build/wild/src/wild-0.8.0/wild/tests/build/libc-integration.c/libc-integration-0.clang-static-host-a6994cb717c80a74.o /build/wild/src/wild-0.8.0/wild/tests/build/libc-integration.c/libc-integration-1.clang-static-host-f4ba4547c81e867b.o -Wl,--dependency-file=/build/wild/src/wild-0.8.0/wild/tests/build/libc-integration.c/libc-integration.c-clang-static-host.d
  Caused by:
    Binary exited (core dumped)  with signal 11:  

failures:
    integration_test::program_name_53___libc_integration_c__  

test result: FAILED. 97 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 7.03s  

Environment

• OS: Arch Linux for Loong64
• Kernel: Linux 6.18.2-arch2-1
• Architecture: LoongArch64 (Loongson-3C5000L @ 2.20 GHz)
• LLVM/Clang: 21.1.6
• Wild version: 0.8.0
• Build context: Package build (PKGBUILD in extra-loong64-build's clean chroot)

[lapla-cogito]

Thanks for the report! However, the failing binary appears to be linked with lld... 🤔

[davidlattimore]

Well spotted. It could of course be a bug in our test. So probably it's necessary to cut the test down to something more trivial that can show whether it's a bug in our test or a bug in lld.

[wszqkzqk]

Thank you for the quick response! As suggested, I've created a debug build and obtained more detailed crash information.

Crash Details

Location: __libc_start_main_impl (glibc initialization phase)
Architecture: loongarch64
Linker: lld (clang --ld-path=/usr/bin/ld.lld)
Mode: static linking
Signal: SIGSEGV at address 0xfffffffffffffff8

Key Findings from GDB

(gdb) bt
#0  0x0000000000051188 in __libc_start_main_impl ()
Backtrace stopped: Cannot access memory at address 0xfffffffffffffff8

(gdb) x/20i $pc-32
0x51184 <__libc_start_main_impl+196>: ld.d $t1, $s8, 16
=> 0x51188 <__libc_start_main_impl+200>: ld.d $a0, $fp, -120
0x5118c <__libc_start_main_impl+204>: ldptr.d $s3, $s8, 0

Crash instruction: ld.d $a0, $fp, -120 - attempting to load from frame pointer offset

Register state at crash:

• $fp (frame pointer): appears to be invalid
• All vector registers (vr0-vr31, xr0-xr31): 0xffffffff... (suspicious - indicates initialization issue)
• Stack pointer ($sp): 0x7ffffffcf940 (valid)

The crash address 0xfffffffffffffff8 (near 0x10000000000000000 - 8) suggests frame pointer ($fp) was not properly initialized during startup.

[mati865]

Even if this is a bug in our tests, the linker should not crash like that. Fixing this is definitely beyond our capabilities.

[davidlattimore]

I didn't think the linker was crashing. It looks like it's the output binary that's crashing, since it says "Failed to run program". What version of LLD are you using? If it's not the latest, then it might be worthwhile trying the latest version, in case it has been fixed.

[wszqkzqk]

Even if this is a bug in our tests, the linker should not crash like that. Fixing this is definitely beyond our capabilities.

The linker is fine but the generated binary crashes

[mati865]

Oh, sorry. I have no idea about Loong64 fork of Arch Linux, but the official Arch Linux has LLVM 22 already. So I guess you should be able to easily test the new LLD version soon.

[wszqkzqk]

Oh, sorry. I have no idea about Loong64 fork of Arch Linux, but the official Arch Linux has LLVM 22 already. So I guess you should be able to easily test the new LLD version soon.

I'm the maintainer of Arch Linux for Loong64 and I've updated LLD to 22 just now. 😂

[wszqkzqk]

I didn't think the linker was crashing. It looks like it's the output binary that's crashing, since it says "Failed to run program". What version of LLD are you using? If it's not the latest, then it might be worthwhile trying the latest version, in case it has been fixed.

There is the same error after updating LLD from 21 to 22.

extra/compiler-rt  22.1.1-1
core/libedit       20251016_3.1-1
extra/libgit2      1:1.9.2-3
extra/llhttp       9.3.1-1
extra/llvm-libs    22.1.1-1
extra/clang        22.1.1-1
extra/lld          22.1.1-1
extra/rust         1:1.94.0-2
extra/rust-musl    1:1.94.0-2

[davidlattimore]

If you cut bits out of the test are you able to find a more minimal version of the test that still segfaults? Also, are you able to reproduce the segfault when compiling and linking the test outside of wild's test framework - i.e. by running clang directly? It looks like for the failing test, linking is done by invoking clang with -static -Wl,--strip-debug -Wl,--gc-sections -Wl,-z,now in addition to object files produced from libc-integration.c, libc-integration-0.c and libc-integration-1.c.

[heiher]

I can't reproduce the same issue on ArchLinux with clang 22, I always get exit code 125:

$ git log -n 1
commit d789d5d6716de3f665ff3da0c53d02dc65e49e3b (HEAD, tag: 0.8.0)
Author: David Lattimore <dvdlttmr@gmail.com>
Date:   Fri Jan 16 16:45:45 2026 +1100

    release: Release 0.8.0 (#1456)

$ cargo test
...
test integration_test::program_name_53___libc_integration_c__ ... FAILED

failures:

---- integration_test::program_name_53___libc_integration_c__ stdout ----
Error: Failed to run program. Binary `/home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration.c-clang-initial-exec-host.ld`. Relink with:
        clang --ld-path=/usr/bin/ld.bfd -fPIC -dynamic -Wl,--strip-debug -Wl,--gc-sections -Wl,-rpath,$ORIGIN -Wl,-z,now -z now -shared -o /home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration-0.clang-initial-exec-host-766dc2a17cb7709a.ld.so /home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration-0.clang-initial-exec-host-766dc2a17cb7709a.o /home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration-0b.clang-initial-exec-host-5c9f9e2aae4d0e14.o -Wl,--dependency-file=/home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration-0.clang-initial-exec-host-766dc2a17cb7709a.ld.d
        clang --ld-path=/usr/bin/ld.bfd -fPIC -dynamic -Wl,--strip-debug -Wl,--gc-sections -Wl,-rpath,$ORIGIN -Wl,-z,now -z now -shared -o /home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration-1.clang-initial-exec-host-e5948587cabd2450.ld.so /home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration-1.clang-initial-exec-host-e5948587cabd2450.o -Wl,--dependency-file=/home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration-1.clang-initial-exec-host-e5948587cabd2450.ld.d
        clang --ld-path=/usr/bin/ld.bfd -fPIC -dynamic -Wl,--strip-debug -Wl,--gc-sections -Wl,-rpath,$ORIGIN -Wl,-z,now -o /home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration.c-clang-initial-exec-host.ld /home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration.clang-initial-exec-host-bdaa77e7a216f703.o /home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration-0.clang-initial-exec-host-766dc2a17cb7709a.ld.so /home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration-1.clang-initial-exec-host-e5948587cabd2450.ld.so -Wl,--dependency-file=/home/hev/rust/wild/wild/tests/build/libc-integration.c/libc-integration.c-clang-initial-exec-host.d
  Caused by:
    Binary exited with unexpected exit code 125: 

failures:
    integration_test::program_name_53___libc_integration_c__

test result: FAILED. 97 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 4.39s

error: test failed, to rerun pass `-p wild-linker --test integration_tests`

$ rustc -vV
rustc 1.96.0-nightly (1e2183119 2026-03-15)
binary: rustc
commit-hash: 1e2183119f0ee19cc26df899e26b04ad0de3475d
commit-date: 2026-03-15
host: loongarch64-unknown-linux-gnu
release: 1.96.0-nightly
LLVM version: 22.1.0

$ clang -v
clang version 22.1.1
Target: loongarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/loongarch64-unknown-linux-gnu/15.2.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/loongarch64-unknown-linux-gnu/15.2.1
Selected GCC installation: /usr/bin/../lib64/gcc/loongarch64-unknown-linux-gnu/15.2.1
Candidate multilib: .;@m64
Selected multilib: .;@m64

wild/wild/tests/sources/libc-integration.c

Lines 301 to 305 in d789d5d

	#ifdef DYNAMIC_DEP
	if (&old_timer_gettime == NULL) {
	return 125;
	}
	#endif

wild/wild/tests/sources/libc-integration.c

Lines 158 to 167 in d789d5d

	// Make sure that we can refer to a non-default version of a symbol from libc.
	#if defined(__x86_64__)
	__asm__(".symver old_timer_gettime, timer_gettime@GLIBC_2.2.5");
	#elif defined(__aarch64__)
	__asm__(".symver old_timer_gettime, timer_gettime@GLIBC_2.17");
	#endif
	// The signature here doesn't actually matter since we don't call it. Symbol is
	// weak to prevent the compiler from assuming that it can never be null.
	int __attribute__((weak)) old_timer_gettime();

Should we handle this for LoongArch64 as well?

[davidlattimore]

Good point. I've sent a PR (#1704) to add old-function definitions for riscv64 and loongarch.

I also noticed / remembered that all the clang tests have Cross:false, so aren't being tested when cross compiling. I did #1703 to make it more possible to enable these tests for cross compiling, although there's still a blocker for doing that.

I noticed that some of the test variants have:

// Seems lld linked binary crashes under QEMU.
//#SkipArch: loongarch64,riscv64

So it seems that we've previously encountered some of these variants crashing. However, when I removed the SkipArch line and ran the test, cross-compiling for loongarch64, it passed on my machine (Ubuntu 25.10). So maybe it is in fact version-specific.