mold
mold copied to clipboard
rui314
Support 32-bit RISC-V
I'm not sure how much important it is, but it would be nice to support RV32. For memory-constrained small systems, I believe there's a reason to compile programs to RV32 instead of to RV64 because it saves 4 bytes for each pointer.
It looks like Unix-like systems uses RV64 exclusively, and most if not all Linux distributions don't even distribute 32-bit libraries. I don't think my SiFive Unmatched RV64 machine supports RV32 instructions, too.
On the other hand, RV32 seems to be very popular in embedded systems. Embedded systems are probably dominated by RV32, and very little are RV64.
At this point, I'm not sure if we want to support RV32. For embedded systems, users probably need some linker script support, but we don't support that. So maybe no one would want to use mold even if it supports RV32.
rv32 is extremely popular especially in FPGA world - and the GNU linker is really a bottleneck for that architecture. There are many many people that would be very happy to use mold instead.
mold doesn't support the GNU-compatible linker script and is unlikely to gain the feature in the future. My concern is that most users of RV32 are also using some linker script features. Isn't that the case?
Edit: Also, what is considered a bottleneck in the GNU linker?
from my experience embedded linker scripts are rather simple and straightforward (at least for standalone projects, without OS running) - porting those to mold-compatible should not be a big deal - although, could you give me some pointers, what are the features of GNU linker script, not supported by mold?
and about the bottleneck, I'm working a on a medium-size embeded project (.text size is roughly 300 KB, no stdlib nor any dynamic libs), and .o files compilation takes ~5 seconds on my 16-core machine (with make -j$(nproc)), and linking those together with GNU linker is ~15 seconds.
mold doesn't support SECTIONS and MEMORY, which I believe most embedded programs are using.
But it supports -Ttext=<address> and -o binary, so you can create a binary blob that can be executed if you place that binary blob at the given address in memory.
Speaking of the GNU linker's performance, it is unbelievably slow. It's like 1000 times slower than mold. It can't be as fast as mold, but there's definitely something wrong with their implementation.
Some tuppence from experience - yes, scripts are very important for embedded systems not only for code location, but for data location (for example sections used by memory allocators) or sections mapped to special hardware. There are commercial linkers which use different format of linker scripts, but all ultimately share almost the same features.
We've added RV32 support to mold. We set up a CI with qemu-riscv32, and all tests are now green. So our RV32 support is on par with other targets. I'm closing bug as fixed.