牛肉一斤蔬菜自助，90 元。

https://github.com/flightlessmango/MangoHud/pull/1418

MangoHud MIPS 也修好了！

GitHub

elfhacks: d_un.d_ptr is relative on mips glibc too by Icenowy · Pull Request #1418 · flightlessmango/MangoHud

In GLIBC, this behavior is controlled by per-architecture definition DL\_RO\_DYN\_SECTION, which is only set to 1 on MIPS (according to the comments, it's because of requirements of MIPS ABI) ...

问题是，我实在不知道为什么在且仅在 RISC-V 上 glibc 突然决定遵守规范了，有知道的吗？

后续：

双倍多多冰发现在 glibc 中只有 RISC-V 和 MIPS 的 DL_RO_DYN_SECTION 宏定义为真，表示 dynamic section 是只读的。

在 ld.so 的 elf_get_dynamic_info() 函数中，如果 dynamic section 可写，则会把上文提到的 d_ptr patch 为绝对地址，所以 RISC-V 和 MIPS 就没有被 patch。

我看你们谁还不承认 RISC-V 是 MIPS 的正统续作

今天需要用 MangoHud 看一下 FPS，发现这玩意在 RISC-V 上竟然不工作！

```

debian@rockos-eswin:~$ mangohud --dlsym glxdemo
MANGOHUD: Can't get dlopen() and dlsym()

```

故事有点长，但是没有 TLDR。

MangoHud 的核心工作原理并不复杂，上面的 mangohud 命令其实只是个 shell 脚本，真正起作用的是 libMangoHud_dlsym.so ，脚本中会通过 LD_PRELOAD 机制替换掉 libc/libdl 的 dlsym() 函数，然后再在自己实现的 dlsym() 中劫持感兴趣 Vulkan/OpenGL 函数，替换成自己的实现，比如通过替换 glxSwapBuffers() 实现在原画面的左上角显示 fps 等信息。

到这就有问题了，MangoHud 要做这些事情，势必要大量用到 dlsym() ，但这个函数已经被自己给替换掉了（？？）

MangoHud 解决这个问题的办法就是用 ld.so 提供的函数去内存中找到真正的那个 libc/libdl 中的 dlsym() ，所以这就免不了要做一些 ELF parsing 的工作。

总之最后肯定要去读 libc/libdl 的 PT_DYNAMIC 表，这个表中给出了各种 section 的地址/信息。

```

typedef struct {
Elf64_Sxword d_tag;
union {
Elf64_Xword d_val;
Elf64_Addr d_ptr;
} d_un;
} Elf64_Dyn;

```

比如当 d_tag 是 DT_SYMTAB 时， d_ptr 中保存的就是符号表的地址。

对于 d_ptr ，elf(5) 是这样说的：

```

This member represents program virtual addresses. When interpreting these addresses, the actual address should be computed based on the original file value and memory base address. Files do not contain relocation entries to fixup these addresses.

```

从这个表述中我们可以知道， d_ptr 保存的并不是绝对地址，而是一个相对的地址，要获取绝对地址只需要加上 elf 的基地址即可： obj\->addr + obj\->dynamic[i].d_un.d_ptr 。

只可惜啊，规范是规范，实现是实现。

在 glibc 中， d_ptr 保存的是绝对地址；在 musl 中，则保存的是相对地址。MangoHud 通过 \#ifdef __GLIBC__ 解决了这个不一致的问题。

只可惜啊，实现是实现，RISC-V 是 RISC-V。

glibc 在 RISC-V 中突然遵守规范了， d_ptr 里面保存的是一个相对值！所以 MangoHud 在 x86_64、AArch64、LoongArch 上都可以工作，但是在 RISC-V 上炸掉了。

不过，我刚刚修复了这个问题：https://github.com/flightlessmango/MangoHud/pull/1417

问题是，我实在不知道为什么在且仅在 RISC-V 上 glibc 突然决定遵守规范了，有知道的吗？

Box64 正在做一个新的功能叫 Box32，用于执行 32 位的 Linux 程序。

对于一个没有 softmmu 的模拟器，这个想法能正常实现的前提就是：程序内所有的指针必须位于 32 位空间，包括 box64 自己。

所以我们使用 \-Ttext\-segment,0x34800000 来将 box64 自己加载到一个低位的地址空间。不过 \-Ttext\-segment 在 lld 和 mold 中并不存在，好在可以使用等价的 \-\-image\-base 来代替。

今天晚上发现使用 mold 编译出来的 box64 二进制 \-\-image\-base 完全没生效，导致 Box32 炸了。研究了一下，发现 mold，lld 和 GNU ld 在这上面的表现各不相同：

1. mold

\-Wl,\-\-image\-base 必须显式和 \-no\-pie 一起使用，否则不生效。如果不加 \-no\-pie 不会有任何报错/警告，只是不生效！

1. lld

\-Wl,\-\-image\-base 和是否 pie 无关。

1. GNU ld

使用 \-Wl,\-Ttext\-segment 会强制隐含 \-no\-pie 。

```
if(WITH_MOLD) # --image-base does not imply -no-pie in mold!

```

哦哦，多么痛的领悟

今天看到了一个帖子说他在 HUAWEI 体验店试图向朋友演示 Matebook E Go 的糟糕触控和输入体验时，无意间发现体验店的机器屏幕触控竟然如丝般顺滑，和自己的机器判若两机。

于是拷贝了体验店机器上触控服务的二进制文件回家替换掉了原有的试了一下，发现华为确实修复了触控问题并偷偷使用，并未向终端用户开放。

我也有一台 Matebook E Go，于是我也试了一下，现在的屏幕打字体验的确已经非常舒适，达到了 iPad 水准。这段文字也是我第一次在这台机器上用屏幕键盘打这么多字。

来源：https://bbs.saraba1st.com/2b/thread-2100755-1-1.html

https://docs.google.com/spreadsheets/u/0/d/1dQYU7QQ-SnIoXp9vVvVjS6Jz9vGWhwmsdbEOF3JBwUg/htmlview

点评：你做得好啊高通

https://box86.org/2024/08/box64-and-risc-v-in-2024/

Box64 and RISC-V in 2024
——— What It Takes to Run The Witcher 3 on RiSC-V

^ 今日产出

https://www.youtube.com/watch?v=5UMUEM0gd34

YouTube

The Witcher 3 running On RiSC-V

The Witcher 3 (latest version from GOG) Running on a Milk-v Pioneer RiSC-V machine, with Wine, DXVK and Box64. Running on REVYOS, the machine is equiped with an AMD RX5500 Graphic Card. The sound was too choppy and has been removed. This video has been…