[Bug]: Cannot execute applications for big core (RVV1.0) compiled with non-vendor toolchain (e.g. GCC 13.2.0)

[pfalz-benni]

What happened

Due to its improvements in vectorization, I want to use a newer version of the GCC toolchain to build applications for the big core that implements RVV1.0. I am able to build the executable with the standard RISC-V GCC 13.2.0 (rv64gc_lp64d_linux_musl_medany), also linking the provided liker script (https://github.com/kendryte/k230_sdk/blob/main/src/big/rt-smart/userapps/linker_scripts/riscv64/link.lds).

When I execute the elf file (a simple main function returning 0) on the big core I get the following error:

[E/DBG] [FATAL ERROR] Exception 13:Load Page Fault
[E/DBG] scause:0x000000000000000d,stval:0x000000000151ccb8,sepc:0x0000000200000014
--------------Dump Registers-----------------
Function Registers:
        ra(x1) = 0x00000000003435ee()
        user_sp(x2) = 0x000000000151ccb0()
        gp(x3) = 0x0000000000000000()
        tp(x4) = 0x00000000deadbeef()
Temporary Registers:
        t0(x5) = 0x0000000000000020()
        t1(x6) = 0x00000000deadbeef()
        t2(x7) = 0x00000000deadbeef()
        t3(x28) = 0x00000000deadbeef()
        t4(x29) = 0x00000000deadbeef()
        t5(x30) = 0x00000000deadbeef()
        t6(x31) = 0x00000000deadbeef()
Saved Registers:
        s0/fp(x8) = 0x00000000014bbc72()
        s1(x9) = 0x00000000014bb342()
        s2(x18) = 0x00000000deadbeef()
        s3(x19) = 0x00000000deadbeef()
        s4(x20) = 0x00000000deadbeef()
        s5(x21) = 0x00000000deadbeef()
        s6(x22) = 0x00000000deadbeef()
        s7(x23) = 0x00000000deadbeef()
        s8(x24) = 0x00000000deadbeef()
        s9(x25) = 0x00000000deadbeef()
        s10(x26) = 0x00000000deadbeef()
        s11(x27) = 0x00000000deadbeef()
Function Arguments Registers:
        a0(x10) = 0x000000000151ccb8()
        a1(x11) = 0x0000000000000000()
        a2(x12) = 0x0000000300000000()
        a3(x13) = 0x0000000300000000()
        a4(x14) = 0x00000000deadbeef()
        a5(x15) = 0x0000000000004000()
        a6(x16) = 0x00000000deadbeef()
        a7(x17) = 0x00000000deadbeef()
sstatus = 0x8000000200046020
        Supervisor Interrupt Disabled
        Last Time Supervisor Interrupt Enabled
        Last Privilege is User Mode
        Permit to Access User Page
        Not Permit to Read Executable-only Page
satp = 0x8000000000007ffb
        Current Page Table(Physical) = 0x0000000007ffb000
        Current ASID = 0x0000000000000000
        Mode = Page-based 39-bit Virtual Addressing Mode
-----------------Dump OK---------------------
riscv64-unknown-linux-musl-addr2line -e main.elf -a -f 0000000200000010
[E/DBG] User Fault, killing thread: main.elf

Comparing the disassemblies of the executables compiled with the vendor GCC 12 (left) and the standard GCC 13 (right) I'm seeing the following differences for the specified program counter:

I'm suspecting that the problem is that the vendor GCC 12 automatically compiles a number of syscall implementations into every executable. I'm guessing RT-Thread tries to call them and that's why the program crashes. Here are examples of the missing syscalls but there are far more:

syscall_set_thread_area
syscall_shmdt
syscall_timer_delete
...
syscall_stat
syscall_munmap
syscall_setrlimit
syscall_dup2
...
syscall_fallocate
syscall_timerfd_settime
get_rtt_syscall
___syscall
...
__syscall
syscall
__syscall_ret
...
__FUNCTION__.0
...
__FUNCTION__.263
syscall_table

If my assumption is correct, could you please provide the source for those syscalls built into the vendor toolchain?

Reproduction steps

1. Build toolchain configured like the provided GCC 12 from the source on https://github.com/riscv-collab/riscv-gnu-toolchain with configuration "rv64gc_lp64d_linux_musl_medany".
2. Write minimal C file:

int main(void)
{
    return 0;
}

3. Build with rv64gc_lp64d_linux_musl_medany/bin/riscv64-unknown-linux-musl-gcc -march=rv64gc -mabi=lp64d -mcmodel=medany -T k230_rtsmart_linker_scripts/riscv64/link.lds --static main.c -o main.elf
4. Transfer main.elf to K230 board and execute it on the big core.

Hardware board

CanMV-K230-V1.1

Software version

v1.5

Bug frequency

100%

Anything else

No response