I made a fair amount of effort to try to support MIPS, but it turned out
that it is much harder than expected. I punted it instead of making
further efforts.
The problem is the MIPS ABI is hostile to the linker in the modern
environment. MIPS object files are still compiled for the small code
model in which GOT entries and data in the small data area are expected
to be accessible with a single machine instruction with a 16-bit
displacement. In other words, .got/.sdata/.sbss are expected to be
smaller than 64 KiB. This might have been a reasonable assumption in the
90s, but it's not suitable for modern applications that can be 1000x
larger than the binaries in the 90s.
MIPS requires the linker to implement tons of workarounds for its legacy
ABI assumptions. Our incomplete MIPS support can build binaries that
pass all our unit tests. However, it needed more effort to support
real-world programs that are larger than our test cases.
At this point, I don't think it is productive to implement workarounds
for the old ABI that is stuck in the 90s. It is honestly annoying to
think about workarounds for the code that is intentionally compiled to
be hostile to the linker. The situation is unfortunate, but if the
Open Source community is still serious about MIPS, they should improve
the ABI and the compiler instead of asking us to implement the legacy
ABI.
Closes https://github.com/rui314/mold/issues/1040
Quote from Arm Cortex-A75 Software Optimization Guide
(PJDOC-466751330-205) p.59:
Consider aligning subroutine entry points and branch targets to
16-byte boundaries, within the bounds of the code-density requirements
of the program. This ensures that the subsequent fetch can maximize
bandwidth following the taken branch by bringing in all useful
instructions.
Although incomplete, this implementation is capable of passing the
following tests:
TRIPLE=mips64el-linux-gnuabi64 bash -x ../test/elf/hello-dynamic.sh
TRIPLE=mips64-linux-gnuabi64 bash -x ../test/elf/hello-dynamic.sh
