？（都 bcc 到我这儿来了，不会是超级 AOE 吧

突然接了个 numpy rvv 1.0 的活，今天搭建了一下开发环境。因为没有可用的 rvv 1.0 硬件，所以最后使用的方案是 x86 archlinux + qemu user 8.2 + riscv archlinux rootfs。

VSCode Remote 直接通过 x86 连到 rootfs 的项目目录下，rootfs 里面配置好 clang、python、meson 以及 virtualenv 之类的开发环境，最后获得了一个接近原生的开发体验。

archriscv 的包版本都很新，clang 直接就有 rvv 1.0 instrinsic 的支持，完全不用折腾工具链。唯一的缺点是 qemu user 的性能确实不太够看，风扇狂转但编译并不快。

原来 latx 中的 x 是这个意思

？

继续 numpy，因为需要支持最新 rvv intrinsic 的编译器，但 gcc 需要等 14 才有，所以切换到了 clang 17。切换过去后编译完运行测试发现某个测例失败，最后整理出来下面这段代码：

import numpy as np

code = 'g' # long double
fnan = np.array(np.nan, dtype=code)
fone = np.array(1.0, dtype=code)
with np.errstate(all='raise'):
    print(np.floor_divide(fnan, fone))

在 clang 编译的 numpy 上，运行这段代码会报错： FloatingPointError: invalid value encountered in floor_divide ，而 gcc 编译器则可以输出预期的 nan 。

于是怀疑是编译器的问题，尝试构造一个最小复现，然后就在 Python 和 C 代码里逛了一晚上，最后终于找到了 floor_divide 调用的底层函数 npy_divmodl() ，又一通精简后，构造出如下复现代码：

bool test(long double a, long double b)
{
    long double m = fmodl(a, b);
    return isless(m, (long double)0);
}

int main(void) {
    fetestexcept(FE_INVALID);
    long double a = NAN, b = 1.0;
    printf("%d\n", test(a, b));
    if(fetestexcept(FE_INVALID)) printf("raised\n");
    return 0;
}

这段代码如果用 clang rv64 编译运行会输出 raised，用 gcc rv64 则不会，经过和 clang x64 交叉验证，发现 clang rv64 是有问题的。

macOS Preview 怎么这么菜，M2 打开 v-intrinsic-spec.pdf 随便搜点东西都直接卡死，也就 4000 页而已。

没活了

刚刚看褪黑素的瓶子上面写着吃完不要驾驶，突然想起来前天晚上吃完之后开美卡，最后一把药劲上来了撞了个损坏度 100%，看来确实没瞎说。

box64 LA64 已经实现了 7z b 所需的所有指令，结果出炉：60% native，127% latx 1.4.4。

详情：https://github.com/ptitSeb/box64/pull/1425#issuecomment-2041074951

小猫咪仔细舔完的毛发，再经过阳光曝晒，会有一股淡淡的膏药味儿

Mov64 Calculator（单寄存器版）迎来重大更新，增加了 LA64 支持：

https://godbolt.org/z/7T5Wq7z5T

https://github.com/DynamoRIO/dynamorio/pull/6691

DynamoRIO 最近增加了一个新的 fake ISA，支持在内部的 IR 和这个新 ISA 之间相互转换，所以用户就可以通过 IR 把 x86/ARM/RV64 的指令转成这个 fake ISA。这个东西乍看起来有点奇怪，仔细探究之后发现，他们是想用这个新的 ISA 来保存 traces 数据：

We want to create a new tool to filter traces of Google workloads for public release.
The new public Google workload traces will contain more information compared to the previous version, while still preserving confidentiality of Google's IP.

但是更重要的一点是，为了公开发布 traces 数据但不泄漏私研指令集的细节。。

C 扩展是如何设计的？出镜率很高，感觉挺合理。

喜报：DynamoRIO 已经可以运行 box64 和 luajit 了

茉莉芽白

味道像泔水，别买

mold debug 小计

今天开发 DynamoRIO RV64 终于受不了 GNU ld 慢出天际的性能，决定掏出 mold 来拯救一下：

mold -run make -j4

然后就发现 mold 竟然 segfault 了，于是就开始了漫长的 debugging。之前给 mold 贡献过一点代码所以算是对 codebase 有一点了解，这方面没有花太多时间。

使用 gcc -v 打印出编译器 driver 调用链接器的命令行，替换成 mold 后运行复现了 segfault。于是 git clone 了 mold 的最新代码，debug build 之后挂上 gdb 拿到了 backtrace。

在 backtrace 前后一通 print 后发现是一个名为 __global_pointer$ 的符号在做 COPYREL 时，因为对应的文件为空，所以触发了 segfault。

__global_pointer$ 是 RISC-V psABI 中规定的一个由链接器在链接期合成的符号，指向 .sdata+0x800 的位置， gp 寄存器会在程序一开始执行的时候就被赋值为 __global_pointer$ 的值并且不会再变，所以用户程序可以方便地通过 gp 寄存器来快速访问 .sdata 数据。

psABI 还规定了如果动态链接的可执行文件中包含 gp -relative 的内存访问，则 __global_pointer$ 必须导出到动态符号表中以供动态链接器使用。

总结一下， __global_pointer$ 由链接器合成，并且在满足条件时，需要导出到可执行文件中的动态符号表中。挺好，看起来没啥问题。

回到问题本身，一通瞎调试和漫长的编译等待后毫无头绪，我突然想到可以精简一下链接命令行，看看能不能缩小一下范围。最后发现只要尝试和某个 .so 链接就可以复现这个问题。然后我惊奇地发现这个 .so 竟然导出了 __global_pointer$ 符号：

$ readelf -s -W xxx.so | grep __global_pointer$
    75: 000000007131b5e4     0 NOTYPE  GLOBAL DEFAULT  ABS __global_pointer$

然后突然想起来同事的科普： .so 文件其实可以同时是一个可执行文件，比如你可以直接执行 /usr/lib/libc.so.6 ，所以动态链接库导出这个符号并不奇怪。

这下问题就说通了，mold 在读取完输入的 object files 之后，会自己合成一堆符号， __global_pointer$ 就是其中之一。但如果读取进来的 object files 已经存在了这个符号，就会和 mold 创建的合成符号产生冲突，那么出现什么问题也都不奇怪了。

总之，最后提交了如下 PR，解决方案是在读取 shared object 符号时，把所有读到的 __global_pointer$ 过滤掉：

https://github.com/rui314/mold/pull/1236

但不知道作者会不会接受这个 PR，因为可能存在更好的修复方式。

省流：
¥499 8 核 PCIe

rv64imafdcv_sscofpmf_sstc_svpbmt_zicbom_zicboz_zicbop_zihintpause

感谢 @sterpr1m 分享的 spike-dasm 跨架构平替，效果：

$ ./la64dasm 700be063
   0:   700be063        vadd.d          $vr3, $vr3, $vr24

代码：

$ cat la64dasm 
#!/usr/bin/env bash

TEMP=$(mktemp)

echo $1 | tac -rs .. | echo "00000000: $(tr -d '\n')" | xxd -r > $TEMP
objdump -b binary -m Loongarch64 -D $TEMP | grep 0:
rm $TEMP