On Fri, 19 Feb 2021, Project Revolution via Gcc wrote:
> Gentlemen: this was fixed, although it's a bit of an odd solution. We
> had to combine both -mno-explicit-relocs and -mno-split-addresses, even
> though per the MIPS compiler documentation explicit relocs supersedes
> the split addresses one. Neither of these options on their own work, and
> it appears as though they're same result individually until you enable
> both of these. It's really odd, but we're not questioning it since it
> resolved our issue.
The GNU extension that permits multiple R_MIPS_HI16 relocations to be
matched with one R_MIPS_LO16 relocation for the ABIs such as o32 that use
the REL relocation format lets the compiler make optimisations that would
otherwise not be possible. A typical use case is moving a LUI instruction
targetted by multiple branches into the respective delay slots, resulting
in overall shrinking of code by one instruction, such as transforming this
(delay-slot instructions conventionally indented by one space):
.set noreorder
# ...
beq $2, $3, $L16
nop
# ...
$L16:
lui $4, %hi(foo)
lw $5, %lo(foo)($4)
# ...
bltz $4, $L16
nop
into this:
.set noreorder
# ...
beq $2, $3, $L16
lui $4, %hi(foo)
# ...
$L16:
lw $5, %lo(foo)($4)
# ...
bltz $4, $L16
lui $4, %hi(foo)
(depending on the execution flow, optimisation options and the ISA level
chosen branch-likely instructions might be used instead).
I agree the outcome of the years of MIPS psABI development reflected in
what GCC and GNU binutils produce nowadays hasn't been properly documented
and sources of information may be scarce. The original SVR4 MIPS psABI
document has had its issues and I believe no exact implementation exists,
including though not limited to SGI IRIX.
That said attempts were made in the past to document the state of affairs
and here's one kept by archive.org that actually mentions the feature:
<https://web.archive.org/web/20140908233719/https://dmz-portal.mips.com/wiki/MIPS_relocation_types#R_MIPS_HI16>.
The original has been lost however in the turbulent history of the various
MIPS companies.
I'm glad to hear you have found a usable workaround. Otherwise I think
we might consider adding an option to GCC to disable this psABI extension,
however offhand I am not sure how difficult it would be to implement.
It looks to me however that you actually have control over the relocation
processing code you have referred, so how about improving it to handle the
GNU R_MIPS_HI16 extension as well?
It should be straightforward as proved by the usual consumers of MIPS
object code, such as the GNU linker, the Linux kernel module loader, etc.
It should give you a smaller code footprint too, to say nothing of the
size regression the use of `-mno-explicit-relocs' usually results in.
Have you considered it?
Maciej
