https://discussion.fedoraproject.org/t/f42-change-proposal-integrate-fex-in-fedora-linux-self-contained/131147

在且仅在 aarch64 上拖家带口地预装一个在且仅在 aarch64 上能运行的 x86-64 模拟器，真行啊

来点 Android gaming 哈哈

世界上最痛苦的事是 debug CI，世界上第二痛苦的事是 bisect。

我了个 RISC-V 啊

今天给 box64 RISC-V 后端增加了 eflags 指令融合的优化，填补了 eflags 模拟的最后一片空白。在 4 个线程的 p7zip benchmark 中，执行效率达到了原生的 70%！

举例来说，对于如下的指令序列：

// set SF/OF/ZF
cmp rax, rbx
// use SF/OF/ZF
jle .label
// flush cmp, set ...
test rcx, rcx
...
.label:

注释中是 box64 的 eflags 依赖计算根据当前指令序列推断出来的信息，即 jle 需要 SF/OF/ZF 来完成 less than or equal 的计算，同时 test 会刷新所有的 flags，所以 cmp 只需要对 jle 负责，完成以上三个 flags 的计算即可。

但这真的足够好吗？只计算 SF/OF/ZF 也非常昂贵，RISC-V 没有龙架构 LBT 这样的专用硬件，这些 flags 的计算全靠手动写汇编来模拟，保守估计也要十几条指令来完成。

但如果从语义的角度出发， cmp+jle 其实就是在做 jump if rax<=rbx 。所以我们要做的其实就是把这两条指令当成一条指令来看待，直接翻译成一条 BGE rbx, rax ！

具体到实现中，虽然涉及到很多实现细节，但其实就是检测连续的两条指令是否符合这个模式，然后将符合的替换为原生的 RISC-V 指令即可，有了已有的依赖计算的帮助，检测工作实际上非常容易。

图中第一个是带有指令融合的跑分，第二个是原生的跑分，第三个是不带指令融合的跑分。

https://box86.org/2024/12/new-version-of-box64-v0-3-2-and-box86-v0-3-8/

Box64 发版，超级大更新！

沉思：
电池健康度的第一个百分点的含金量是否可以类比为油箱里的第一格。

给 Box64 加了 gdbjit 功能

上一条好多🤔，那解释一下吧

gdbjit 是 gdb 为了解决 jit 出来的代码没有调试符号问题搞出来的灵车方案，其原理是 jit 引擎在产生一个代码块的同时，也产生一个带有 debug 符号的 in memory object file，然后通过一个灵车的机制通知 gdb 这个 object file 产生完毕即可。这样当用户在 gdb 中调试 jit 产生的代码的时候，就有调试符号了。

文档：https://sourceware.org/gdb/current/onlinedocs/gdb.html/JIT-Interface.html

这个其实很多运行时都支持，比如 v8、LLVMJIT、LuaJIT ...

另外我发现 gdbjit 作为一个理应架构无关的东西，在 AArch64 上是好的，但是在 RISC-V 和龙架构上都是炸的。

这两天陷入到了 gdb 的代码中一直找不到原因，直到今天决定在 AArch64 上构建一个 latest gdb 来对比一下执行流，然后就发现是新版本 gdb 的 regression ...

你妈的，我不要 bisect gdb 啊草

这辈子有了

修好了！！！！！！！！！！！！！！！！

https://inbox.sourceware.org/gdb-patches/20241221083035.80249-1-liuyang22@iscas.ac.cn/T/

Patch 发出去了

4k 页的龙芯才是好龙芯。

你妈的，费劲巴拉的给别人 review，然后发现对方在用 ChatGPT，草！

气炸了