mold
mold copied to clipboard
[FEATURE REQ/BUG REP] SH4 endianas
The existing SuperH code is endianess defined by the host system, wich would either make littel-endian or more possible big-edian not work depending on what opposite the host is using.
TL;DR:
- SH4 little-endian only works on litte-enadian hosts
- SH4 big-endian only work on big-endian hosts
mold support big-endian sh4 as a target. As far as I know, big-endian sh4 systems are extremely rare if ever exists. sh4 is becoming a retro computer, though. Are you using sh4?
Yes I am using big-endian SH4 as part of a calculator in wich modding community I am. Mold fails by reading an absurdly high e_shnum in little-endian from the big-endian field. elf/input-files.cc:84
It shouldn't be too hard to support sh4eb, but the problem is there's no easy way to test it. Ubuntu provide only sh4 little endian cross toolchains, so we cannot build object files for sh4eb and try to link them using mold (that's how we test mold). Given the situation, it is realistically not very practical to support sh4eb.
If you want to try yourself, you may try to change the following line from true to false.
https://github.com/rui314/mold/blob/8cd85aaa29093a315d2b905bdcab379ac922e73a/elf/elf.h#L2198
I also want to point out that mold does not depend host endianness. You can for example build a big-endian sparc executable on a little-endian machine using mold. Speaking of SH4, it's just that mold supports only little-endian SH4 output.
I made a custom mold that supports sh4eb instead of the little-endian variant. Is there intrest in bringing it upstream from this side and if so what is the plan?
https://github.com/rui314/mold/compare/main...QBos07:mold:main
As I said, supporting sh4eb itself isn't hard, but testing it is hard. We cannot support it unless we can run our unit test suite for the target.
I have some time lately and want to get this finally out. I found some toolchain here and want to incorperate them into my fork. I figured that the github runner yaml and CMakeLists in the test directory would need some change. My question is if you know of some other places I might need to adapt?
We can support sh4be if we need to, but what device do you actually own that runs a SH4 processor in the big-endian mode? My understanding is that almost all SH-4 devices run in the little-endian mode.
CASIO calculators use shbe chips and they have a pretty big modding community. On the other hand, mold is currently the only linker with proper SH support. Binutils is the only other one and is stuck in 2016 or something and can't link dynamicly/pie.
And that CASIO calculators run SH4 in big endian mode?
Yes, a custom undocumented sh4aeb-dsp-nofpu variant for there newset model for example. They are basicly the go to of calculators in Germany and France and allowed for final exams 'n' stuff
Let me know if the above change works for you.
Holy shit, thanks! I appreciate your time investment. This is huge for us. I look over the failing test to see if there is still something I might do
Yeah, but first please test it in your environment to make sure that my change actually works for real big-endian sh4 machines.
The test errors seem to come from qemu crashing from traps and the implementations for the target being rougth. The SH ecosystem has rotten since quite some time ...
This is not a failure in mold.