The binutils sframe maintainer has changed their email address.
https://sourceware.org/pipermail/binutils/2026-March/
Meanwhile, I heard that the person who pushed for llvm sframe has left Google.
While I am suspicious of SFrame' long-term maintenance, IBM is doubling down on SFrame by adding a PowerPC port alongside s390x -- a strange move.
I strongly recommend that anyone proposing a new unwind format for the Linux kernel take the time to rethink and refine the design.
---
On SFrame v3:
Cherry-picking a large number of patches right before the binutils 2.46 release effectively introduces insufficiently validated changes during the stabilization period of the release branch. More critically, rushing v3 in may have foreclosed improvements that community feedback could have delivered before the format was finalized.
meowray
@meowray@hachyderm.io
mastodon
4.5.9
0
Followers
0
Following
Joined November 18, 2022
Website:
Posts
meowray
@meowray@hachyderm.io
hachyderm.io
百码归模，我看还是要归。有些同志认为，只能投喂精品代码，不能投喂屎山。这种看法，表明他们对数据飞轮的方针很不理解。一般说来，纯粹的乱码当然不让喂。但是，它不以乱码的面貌出现，而以"经过review的生产代码"的面貌出现，那就只好让它喂，这样才有利于模型对它进行鉴别和泛化。
仓库里长着两种东西，一种叫优雅实现，一种叫历史债务。历史债务年年要还，一年要还几次。你说只要喂精品，不要喂屎山，那就等于要模型只读过教科书，没上过战场。话尽管那样讲，凡是上过生产环境的都知道，只要你不去动手重构，屎山实际上还是有那么多。
屎山有个好处，翻过来就是训练语料。你说它没用？可以化腐朽为神奇。程序员需要年年跟屎山作斗争，我们的大模型也需要年年在屎山里摸爬滚打。所谓能干活的模型，就是在屎山里滚出来的。你债长，我就学。这个对立面是不断出现的。屎山一万年还会有，所以我们也要准备投喂一万年。
去年是多事之秋，大厂引蛇出洞、向维护者普发额度；维护者慷慨赴义、竞相投喂。今年仍是多事之秋，各路精品代码还要继续出笼，为未来的数字分身修撰家谱。
此所谓：百川归海，含笑入参数。
仓库里长着两种东西，一种叫优雅实现，一种叫历史债务。历史债务年年要还，一年要还几次。你说只要喂精品，不要喂屎山，那就等于要模型只读过教科书，没上过战场。话尽管那样讲，凡是上过生产环境的都知道，只要你不去动手重构，屎山实际上还是有那么多。
屎山有个好处，翻过来就是训练语料。你说它没用？可以化腐朽为神奇。程序员需要年年跟屎山作斗争，我们的大模型也需要年年在屎山里摸爬滚打。所谓能干活的模型，就是在屎山里滚出来的。你债长，我就学。这个对立面是不断出现的。屎山一万年还会有，所以我们也要准备投喂一万年。
去年是多事之秋，大厂引蛇出洞、向维护者普发额度；维护者慷慨赴义、竞相投喂。今年仍是多事之秋，各路精品代码还要继续出笼，为未来的数字分身修撰家谱。
此所谓：百川归海，含笑入参数。
2
0
0
meowray
@meowray@hachyderm.io
hachyderm.io
Revised https://maskray.me/blog/2025-08-24-understanding-alignment-from-source-to-object-file on LLVM's recent .prefalign change. Filed a GNU Assembler feature request https://sourceware.org/bugzilla/show_bug.cgi?id=33943 ("gas: .prefalign directive for body-size-dependent function alignment") and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124314 ("Emit .prefalign for body-size-dependent function alignment")
0
0
0
meowray
@meowray@hachyderm.io
hachyderm.io
https://maskray.me/blog/2026-02-22-bit-field-layout Bit-field layout
4
0
1
meowray
@meowray@hachyderm.io
hachyderm.io
https://maskray.me/blog/2026-02-16-call-relocation-types Call relocation types
Some architectures use two ELF relocation types for a call instruction: (x86, m68k, s390(x), etc)
Some architectures use two ELF relocation types for a call instruction: (x86, m68k, s390(x), etc)
0
0
0
meowray
@meowray@hachyderm.io
hachyderm.io
https://github.com/llvm/llvm-project/pull/180912 "[LLD][ELF][RISCV] Support big-endian RISC-V linking" This reminds me of Linus Torvalds's
https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%2BHfB4n6Wj6zM5H5EghUMfpXSCzyQVSfA@mail.gmail.com/t/#mce138059dc56014643bbda330810183031ef5c06 "New endianness problems are somebody ELSES problem"
https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%2BHfB4n6Wj6zM5H5EghUMfpXSCzyQVSfA@mail.gmail.com/t/#mce138059dc56014643bbda330810183031ef5c06 "New endianness problems are somebody ELSES problem"
1
0
0
meowray
@meowray@hachyderm.io
hachyderm.io
Quality, Velocity, Open Contribution — pick two. If you try for all three, you get none — the maintainers burn out, the project becomes unsustainable.
Lua and SQLite picked quality, and dropped both velocity and open contribution.
When your project is mature enough, you can afford to.
For a project like LLVM, open contribution is not optional — so you're really choosing between quality and velocity.
LLM-aided development dramatically increases contribution volume without increasing reviewer capacity.
LLM-aided review may help at the margins — catching mechanical issues, summarizing patches — but the core bottleneck is human judgment.
Lua and SQLite picked quality, and dropped both velocity and open contribution.
When your project is mature enough, you can afford to.
For a project like LLVM, open contribution is not optional — so you're really choosing between quality and velocity.
LLM-aided development dramatically increases contribution volume without increasing reviewer capacity.
LLM-aided review may help at the margins — catching mechanical issues, summarizing patches — but the core bottleneck is human judgment.
3
0
2
meowray
@meowray@hachyderm.io
hachyderm.io
Asked Claude Code silly questions 'What's the code review style of XXX?'. Still not sure how well it actually performs reviews in someone's style, but the responses are fascinating. https://gist.github.com/MaskRay/9ebed65d9b9056bc6519001b237fdaa7
2
0
0
meowray
@meowray@hachyderm.io
hachyderm.io
claudes-c-compiler禁用了RISC-V assembler relaxation，但没有发现真实原因是没有采用fragment-based设计。
16-bit x86没有弄对看上去是训练样本太少。
我在lld/ELF和blog里提了这个不准确的术语"absolute relocation"太多次好像误导了它。
它能处理asm goto还是挺惊人的。
16-bit x86没有弄对看上去是训练样本太少。
我在lld/ELF和blog里提了这个不准确的术语"absolute relocation"太多次好像误导了它。
它能处理asm goto还是挺惊人的。
0
0
1
meowray
@meowray@hachyderm.io
hachyderm.io
Interesting ld.so optimization: When a dynamic relocation references a defined symbol, get the hash from the GNU hash table. DT_GNU_HASH only stores 31 bits (the LSB is cleared for chain termination). The missing bit can be recovered https://openwall.com/lists/musl/2026/02/03/3
Updated my https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash
Updated my https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash
0
0
0
meowray
@meowray@hachyderm.io
hachyderm.io
https://maskray.me/blog/2026-02-01-lld-22-elf-changes lld 22 ELF changes
highlights: Distributed ThinLTO, Pointer Field Protection, RISC-V vendor relocations
highlights: Distributed ThinLTO, Pointer Field Protection, RISC-V vendor relocations
1
0
0