Support C-SKY (experimental)

[taiki-e]

Of the CPU architectures supported by Rust, this is the last architectures not supported by this crate.

The build passed, but has not yet been tested. The qemu binary mentioned on the platform support docs does not work with even a minimal program due to the following error: UPDATE: See #32 (comment)

qemu: 0x00009ab4: unhandled CPU                 exception 0x4 - aborting
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f16efded943

TODO: ldex/stex is ck860* only? #32 (comment) UPDATE: See #32 (comment)

[Dirreke]

Hi, Thanks for the job. How can I help test it? I have no idea how to solve the qemu. As I tested, QEMU always crashes on dynamic-linked program. Can we get a static program? Or maybe I can get a physical device to test it. So just tell me how to test it.

[taiki-e]

@Dirreke Thanks for your advice and sorry for the late response.

After properly static linking, basic functions like standard output started working, but then it crashed.

target_has_cas: true
test test_atomic_isize ... 
qemu: 0x0000fd76: unhandled CPU                 exception 0x4 - aborting
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7fffff81b9a4

Then I found that this crash could be avoided by passing -cpu ck860 (or other ck860* cpus) to qemu-cskyv2.

target_has_cas: true
test test_atomic_isize ... 
ok
test test_atomic_usize ... 
ok
test test_atomic_i8 ... 
ok
test test_atomic_u8 ... 
ok
test test_atomic_i16 ... 
ok
test test_atomic_u16 ... 
ok
test test_atomic_i32 ... 
ok
test test_atomic_u32 ... 
ok

Also, when I disabled the code using ldex/stex, it also worked with the default cpu (and -cpu ck810 and -cpu ck80[3457]), so looks like the crash with such cpus is due to uses of ldex/stex or the code around it. Considering your comment at rust-lang/rust#115577 (comment), is there an error in the documentation or QEMU?

target_has_cas: false
test test_atomic_isize ... 
ok
test test_atomic_usize ... 
ok
test test_atomic_i8 ... 
ok
test test_atomic_u8 ... 
ok
test test_atomic_i16 ... 
ok
test test_atomic_u16 ... 
ok
test test_atomic_i32 ... 
ok
test test_atomic_u32 ... 
ok

Test code is in tests/no-std-linux and can be run by ./tools/no-std.sh csky-unknown-linux-gnuabiv2. In CI, it is run in no-std (nightly) job.

Ideally, I'd like to run a full test suite by ./tools/test.sh, but for now, it's not working due to the following build error.

error: linking with `/home/taiki/gcc-csky-linux-gnuabiv2/bin/csky-abiv2-linux-gcc` failed: exit status: 1
  |
  = note:  "/home/taiki/gcc-csky-linux-gnuabiv2/bin/csky-abiv2-linux-gcc" "/tmp/rustcPUho6R/symbols.o" "<17 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "/Users/taiki/projects/sources/taiki-e/atomic-maybe-uninit/target/csky-unknown-linux-gnuabiv2/release/deps/{libpanic_unwind-235beb5f131ae3fe,libfastrand-ba1e622a303c3f46,libquickcheck-fb0bdfd09eb5c236,librand-15c132d1c4914e27,librand_core-6a294207728b94b3,libgetrandom-05377282a8abcea3,liblibc-17cfe53b300994ef}.rlib" "-lc" "-lm" "-lrt" "-lpthread" "/Users/taiki/projects/sources/taiki-e/atomic-maybe-uninit/target/csky-unknown-linux-gnuabiv2/release/deps/{libcfg_if-0919f9e184d13b49,libtest-701f8a49f355586b,libgetopts-80937c8220c50744,librustc_std_workspace_std-bede81c9fa9e9f93,libstd-393af90b64503b7e,libobject-87f92b564eada08e,libmemchr-7545a0d02a0df69d,libaddr2line-f32d3ffa70f22a8b,libgimli-d1637fcc56a8aaf9,libcfg_if-ec02d3adb7fb2ec9,librustc_demangle-24ca359100c3dc7a,libstd_detect-5213b06f8a28eab4,libhashbrown-60de30d86ab04d4f,librustc_std_workspace_alloc-c61c2d10d2d2652d,libminiz_oxide-f63375487a6f67f5,libadler2-e3d659a0901ca108,libunwind-b5e01e8ae7c4e449,liblibc-c7a0db2d9bcac598}.rlib" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-lgcc_eh" "-lgcc" "-lc" "/Users/taiki/projects/sources/taiki-e/atomic-maybe-uninit/target/csky-unknown-linux-gnuabiv2/release/deps/{librustc_std_workspace_core-dbeda5d7463615f5,liballoc-19b12f61daa17eaf,libcore-bf21f9f65e4880d9,libcompiler_builtins-e23363094c0e3106}.rlib" "-L" "/tmp/rustcPUho6R/raw-dylibs" "-Wl,-Bdynamic" "-l:libatomic.a" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "<sysroot>/lib/rustlib/csky-unknown-linux-gnuabiv2/lib" "-o" "/Users/taiki/projects/sources/taiki-e/atomic-maybe-uninit/target/csky-unknown-linux-gnuabiv2/release/deps/atomic_maybe_uninit-cdfb236dd86fa7ff" "-Wl,--gc-sections" "-static" "-no-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: /home/taiki/gcc-csky-linux-gnuabiv2/bin/../csky-linux-gnuabiv2/libc//usr/lib/libpthread.a(lowlevellock.o): In function `__lll_lock_wait_private':
          (.text+0x0): multiple definition of `__lll_lock_wait_private'
          /home/taiki/gcc-csky-linux-gnuabiv2/bin/../csky-linux-gnuabiv2/libc//usr/lib/libc.a(libc-lowlevellock.o):(.text+0x0): first defined here
          collect2: error: ld returned 1 exit status

[Dirreke]

Ideally, I'd like to run a full test suite by ./tools/test.sh, but for now, it's not working due to the following build error.

I've been a bit busy recently, so I may not have looked into it very thoroughly. However, my initial investigation suggests the compilation error originates from the quickcheck crate, and I see a similar failure when running ./tools/test.sh with +crt-static enabled for ARMv7.

[taiki-e]

However, my initial investigation suggests the compilation error originates from the quickcheck crate, and I see a similar failure when running ./tools/test.sh with +crt-static enabled for ARMv7.

Thanks for the investigation! I'm not sure why, but quickcheck indeed to be related, disabling quickcheck-related tests allowed the full test suite to build.

In multi-threaded tests, hangs or the following assertion failures in glibc or pthread occur (can be reproduced without this crate's atomics). Considering the discussion in rust-lang/rust#117306 that libatomic is broken and likely causing data races, this is an understandable result.

pthread_mutex_lock.c:79: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

arena.c:960: __malloc_arena_thread_freeres: Assertion `a->attached_threads > 0' failed.

---

As for the issue that QEMU cannot run tests using ldex/stex when non-ck860 CPU is specified (#32 (comment)), looking at the Linux kernel code, only ck860 set CPU_HAS_LDSTEX, so it seems QEMU is correct here.

https://github.com/torvalds/linux/blob/cbf33b8e0b360f667b17106c15d9e2aac77a76a1/arch/csky/Kconfig#L200-L215

config CPU_CK810
	bool "CSKY CPU ck810"
	select CPU_HAS_HILO
	select CPU_NEED_TLBSYNC

config CPU_CK807
	bool "CSKY CPU ck807"
	select CPU_HAS_HILO

config CPU_CK860
	bool "CSKY CPU ck860"
	select CPU_HAS_TLBI
	select CPU_HAS_CACHEV2
	select CPU_HAS_LDSTEX
	select CPU_HAS_FPUV2

Updated PR to check the -C target-cpu and target's default cpu, and enabling CAS/RMW which requires ldex/stex only on ck860*. (It would be better if LLVM and rustc had a target feature for this purpose.)

[taiki-e]

As for "multiple definition of `__lll_lock_wait_private'" error, it maybe related to https://sourceware.org/bugzilla/show_bug.cgi?id=15648 that was fixed in glibc 2.34.

[taiki-e]

Ideally, I'd like to run a full test suite by ./tools/test.sh, but for now, it's not working due to the following build error.

However, my initial investigation suggests the compilation error originates from the quickcheck crate, and I see a similar failure when running ./tools/test.sh with +crt-static enabled for ARMv7.

Thanks for the investigation! I'm not sure why, but quickcheck indeed to be related, disabling quickcheck-related tests allowed the full test suite to build.

This has been resolved by applying a patch to quickcheck that uses fastrand instead of rand.