duo: atoi crash

[unicornx]

bsp/cvitek/cv18xx_risc-v/ master 或者 5.1.0

简单的调用 atoi 函数会导致异常：

#include <rtthread.h>
#include <stdio.h>
#include <stdlib.h>

static int test(int argc, char *argv[])
{
    int v;
    v = atoi("100");
    rt_kprintf("v is %d\n", v);

    return RT_EOK;
}
MSH_CMD_EXPORT(test, test);

log 如下：

Unhandled Exception 2:Illegal Instruction
scause:0x0x0000000000000002,stval:0x0x0000000000000000,sepc:0x0x00000000802001ce
--------------Dump Registers-----------------
Function Registers:
        ra(x1) = 0x0x0000000080218002   user_sp = 0x0x0000000080259040
        gp(x3) = 0x0x0000000080234bb8   tp(x4) = 0x0x00000000deadbeef
Temporary Registers:
        t0(x5) = 0x0x0000000000000120   t1(x6) = 0x0x00000000deadbeef
        t2(x7) = 0x0x0000000080258f30
        t3(x28) = 0x0x00000000deadbeef  t4(x29) = 0x0x00000000deadbeef
        t5(x30) = 0x0x00000000deadbeef  t6(x31) = 0x0x00000000deadbeef
Saved Registers:
        s0/fp(x8) = 0x0x0000000080259080        s1(x9) = 0x0x00000000deadbeef
        s2(x18) = 0x0x00000000deadbeef  s3(x19) = 0x0x00000000deadbeef
        s4(x20) = 0x0x00000000deadbeef  s5(x21) = 0x0x00000000deadbeef
        s6(x22) = 0x0x00000000deadbeef  s7(x23) = 0x0x00000000deadbeef
        s8(x24) = 0x0x00000000deadbeef  s9(x25) = 0x0x00000000deadbeef
        s10(x26) = 0x0x00000000deadbeef s11(x27) = 0x0x00000000deadbeef
Function Arguments Registers:
        a0(x10) = 0x0x000000008022c7f8  a1(x11) = 0x0x00000000802590a8
        a2(x12) = 0x0x00000000802590a8  a3(x13) = 0x0x00000000802590a8
        a4(x14) = 0x0x0000000000000009  a5(x15) = 0x0x0000000000000009
        a6(x16) = 0x0x0000000000000074  a7(x17) = 0x0x00000000deadbeef
sstatus = 0x0x0000000200040120
        Supervisor Interrupt Disabled
        Last Time Supervisor Interrupt Enabled
        Last Privilege is Supervisor Mode
        Permit to Access User Page
        Not Permit to Read Executable-only Page
satp = 0x0x0000000000000000
        Current Page Table(Physical) = 0x0x0000000000000000
        Current ASID = 0x0x0000000000000000
        Mode = No Address Translation/Protection Mode
-----------------Dump OK---------------------
--------------Thread list--------------
current thread: tshell
--------------Backtrace--------------

[BernardXiong]

好像很神奇呢，或许是对齐的缘故？atoi是libc的函数，目前用的libc是哪个

[flyingcys]

v5.1.0正常，master有问题

[unicornx]

网上看到一篇文章，可能和这个问题有关系，just FYI：https://zhuanlan.zhihu.com/p/619893693

[unicornx]

当前 小核和 大核的 gcc 用的都是 Xuantie-900-gcc-elf-newlib-x86_64-V2.8.1，但是大核需要使用 musl 的gcc，对大核换成 musleabi 的之后就不会 crash 了。

有个问题，我用的 musleabi 的 gcc 是 https://download.rt-thread.org/rt-smart/riscv64/riscv64-linux-musleabi_for_x86_64-pc-linux-gnu_180881.tar.bz2，换成其他的 musl gcc 都不行，是不是 rtt 有特殊的需求？这个问题已经提 issue，参考https://github.com/RT-Thread/rt-thread/issues/9049 的讨论。

后面具体怎么解，还要看看能否将大核和小核的工程尽量统一起来。参考 https://github.com/RT-Thread/rt-thread/pull/9028 的讨论。

[unicornx]

v5.1.0正常，master有问题

5.1.0 应该也不行吧

[unicornx]

小核目前用 newlib gcc 是好的。

[unicornx]

RFC:

为了解决这个问题，打算将 cv18xx_riscv-v 默认切换到 musl gcc。即修改 bsp/cvitek/cv18xx_risc-v/rtconfig.py 中对 EXEC_PATH 和 PREFIX， 具体参考 bsp/qemu-virt64-riscv/rtconfig.py

比较担心的是，我这里一直用 newlib gcc 编译大核的，换成 musl gcc 后影响会有多大？

[polarvid]

libc 的差别我理解应该没有太严重的功能影响，特别是系统内核这边用到的主要是字符处理、数学库这类的。

[unicornx]

一个有趣的发现：

目前主线上自从 ”beee77f372 feat: support ARCH_REMAP_KERNEL on libcpu/c906 (#9123)" 合入后，atoi 的问题就不见了。使用 newlib gcc 一样工作正常。

目前来看，这个问题和网上的 https://zhuanlan.zhihu.com/p/619893693 这个分析是一个道理。

没有合入 beee77f372 之前，libcpu/risc-v/t-head/c906/startup_gcc.S 中没有为 boot_hartid 明确指定的 section，

boot_hartid: .int
    .global         boot_hartid
......
    /* save hartid */
    la t0, boot_hartid                /* global varible rt_boot_hartid */
    mv t1, a0                         /* get hartid in S-mode frome a0 register */
    sw t1, (t0)                       /* store t1 register low 4 bits in memory address which is stored in t0 */

这导致链接后 boot_hartid 被默认放到 text section，和 atoi 函数的地址一样，这会导致 save hartid 的动作覆盖了 atoi 的 text。具体见 rtthread.map 中符号的地址分布：

...
 .text          0x00000000802001c6        0x0 build/kernel/libcpu/risc-v/t-head/c906/startup_gcc.o
                0x00000000802001c6                boot_hartid
 .text          0x00000000802001c6       0x28 /home/u/ws/bin/rtt-xuantie900-newlib-gcc/Xuantie-900-gcc-elf-newlib-x86_64-V2.8.1/bin/../lib/gcc/riscv64-unknown-elf/10.4.0/../../../../riscv64-unknown-elf/lib/rv64imac/lp64/libc.a(lib_a-atoi.o)
                0x00000000802001c6                atoi
                0x00000000802001da                _atoi_r

最终导致执行 atoi 时发生异常。

原先换成 musl gcc 不出问题，只是因为不同编译器分配地址不同，正好没有覆盖 atoi 而已，并没有本质上解决这个潜在问题。

合入 beee77f372 后，明确将 boot_hartid 分配到 .data section，杜绝了这个问题。

--- a/libcpu/risc-v/t-head/c906/startup_gcc.S
+++ b/libcpu/risc-v/t-head/c906/startup_gcc.S
...... 
-boot_hartid: .int
-    .global         boot_hartid
+    .data
+    .global boot_hartid    /* global varible rt_boot_hartid in .data section */
+boot_hartid:
+    .word 0xdeadbeef

[unicornx]

关闭这个 issue，目前 master 已经不会出错。