[FEATURE REQ/BUG REP] SH4 endianas

[QBos07]

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

[rui314]

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?

[QBos07]

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

[rui314]

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.

mold/elf/elf.h

Line 2198 in 8cd85aa

static constexpr bool is_le = true;

[rui314]

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.

[QBos07]

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?

[QBos07]

main...QBos07:mold:main

[rui314]

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.