Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension?

["Maciej W. Rozycki" <macro@orcam.me.uk>]

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