Xi Ruoyao

GCC patch proposed at https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593397.html.

> > > > > 是不是没有加入`nop`指令（这个手册应该是有的）？ > > > > > 另外是不是添加 > > > > > > > > > > * nop > > > > > *...

我感觉 move 这个东西还是文档记录一下好，不然大家会自己乱写各种变体 (`add $rd, $rs, $r0`, `addi $rd, $rs, 0`, `ori $rd, $rs, 0`, ...)。另外不知道不同变体会不会导致性能的变化 (我不是很熟悉 CPU 内部的流水线这些东西)。

> P.S. 上面提到的 `libpthread.so` 的问题，gcc 如果不改，是过不了编译的：[xen0n/gcc@17d5d4f](https://github.com/xen0n/gcc/commit/17d5d4feb788b83488b1fa70c1dcaf1a4d21d601) 参考这里。 这个并不必要吧，LFS 从 glibc-2.33 升级到 2.34 的时候没有发现这个问题，我自己在 LoongArch 上编译系统也没有遇到这个问题。 glibc-2.34 提供了空的 libpthread.a 和 libpthread.so.1，理论上应该足够向下兼容。

> * 已有商业系统的 `NSIG`、`struct sigcontext` 等等内容与上游接受的内容不同 这个是最烦的。我的想法是引入一组和旧 ABI 兼容的系统调用 (上游很可能不会接受，但是可以写成单独的内核模块)，然后用 LoongArch 的二进制翻译扩展在运行旧代码时把系统调用号直接改掉。但是并不知道可不可行，毕竟二进制翻译扩展的细节还没公开。

或者能否用 personality 机制 (`man:personality(2)`)？

> > 这个是最烦的。我的想法是引入一组和旧 ABI 兼容的系统调用 (上游很可能不会接受，但是可以写成单独的内核模块)，然后用 LoongArch 的二进制翻译扩展在运行旧代码时把系统调用号直接改掉。但是并不知道可不可行，毕竟二进制翻译扩展的细节还没公开。 > > 这个事情前面提到的 `ptrace` 就能做了。当然如果被执行的程序本身对特权操作的需求比较奇葩，可能会出现别的问题，但这跟新旧世界兼容无关，是拿 `ptrace` 干活都会碰到的通病。 ptrace 的问题是如果系统调用比较多 (比如频繁 read/write 文件) 会很慢。

> > 这个并不必要吧，LFS 从 glibc-2.33 升级到 2.34 的时候没有发现这个问题，我自己在 LoongArch 上编译系统也没有遇到这个问题。 > > 在我的 Gentoo 移植工作中，这个调整是必须的，否则链接有问题。 > > > glibc-2.34 提供了空的 libpthread.a 和 libpthread.so.1，理论上应该足够向下兼容。 > > 不够：正因为是空的，新世界 `ld.so` 装载旧世界程序的时候就会想在里面找符号，就找不到，一定会死。 空的 libpthread.so.1...

如果要动 eflags ，那可以新世界的 ABI 版本 (`eflags[7:6]`) 从 1 开始，之前的都叫 0。不同 ABI 版本交叉链接直接报错。

> > 如果要动 eflags ，那可以新世界的 ABI 版本 (`eflags[7:6]`) 从 1 开始，之前的都叫 0。不同 ABI 版本交叉链接直接报错。 > > 我们现在可以确认的是，所有旧世界程序都是 LP64D ABI，但旧世界表示 LP64D 的方法是让 `e_flags` 取 3，这就很尴尬了；如果是 0 那很好办，0 只能跟 0 interlink，非 0...