[PATCH] MIPS/GAS: Use addiu instead of addi in test elf-rel

[Maciej W. Rozycki]

Hi Nick,

> >   The 64-bit MIPS psABI actually specified ADDI rather than ADDIU for
> > certain address load sequences and <sys/asm.h> (or Linux <asm/asm.h>)
> > macros used to use it.  We abandoned this practice at one point, but I
> > find to deliberately remove verification for this instruction rather
> > gratuitous.  This should have been done in a better way, still without
> > sacrificing MIPSr6 coverage.
> 
> By having an r6 version of the test perhaps ?

 Yes.  Besides, I think R6 should actually work too, though with different 
output, by interpreting ADDI as a macro and expanding it to an equivalent 
LI/ADD instruction pair (with any relocation applied to the LI operation).  
That has been the principle of the MIPS assembly language dialect, and it 
is how pre-R6 to R6 transition was supposed to address backwards source 
compatibility and minimise impact on existing software (similarly to the 
transition from the conventional MIPS ISA to the original microMIPS ISA).

> >   In any case the change description shouldn't have been dropped from the
> > commit, which I can see has been correctly prepared for applying via `git
> > am'.  Right now it presents itself in the repo as if it's been done with
> > no justification whatsoever, and certainly whoever comes across it in a
> > few year's time will scratch their head about it.
> 
> This is my fault.  I have no idea how to use 'git am', instead I just apply
> patches by hand.  If you do not mind, please could you fix this for me so
> that the correct description is there ?

 Unfortunately a commit description, once the commit has been pushed, can 
only be retrofitted by means of a rebase and we forbid (non-fast-forward) 
rebases by policy, as doing so would disturb people's trees out there.

 Applying patches by hand must be a pain, I sympathise.  My e-mail client 
has a "pipe" command, which feeds the message selected, usually one that's 
currently shown, though several messages can be fed all at once too, in 
its cooked form (i.e. as output to the terminal, rather than the raw form, 
QP or Base64, it has been encoded for transport) to the standard input of 
an arbitrary shell pipeline.

 So I pipe a message to be applied to: `cd /path/to/repository && git am'.  
I can then push the contents of /path/to/repository to their origin right 
away (I usually use commands like `git show' beforehand to verify the 
result of `git am' meets my expectations; at this point I can still make 
final tweaks with `git commit --amend').

 If your e-mail client has no such feature, then I do hope it can at least 
export a message complete with its headers to a text file, which you can 
feed similarly: `cat message.txt | (cd /path/to/repository && git am)' or 
suchlike.

 I do recommend using `git am' whenever possible, as it will accurately
record commit authorship according to the `From:' message header or any 
override given in the first line of the message body, it will transfer the 
`Subject:' header to the change heading, and it will make the message body 
(sans any `From:' override) the change description.  And it will of course 
apply the patch included as well.  All of which automatically, making it 
easier to avoid human mistakes.

 I do encourage reading the git-am(1) man page for further details, and if 
you still have any questions afterwards, then feel free to ask me directly 
and I'll strive to answer them.

  Maciej