Re: MIPS patch to correct the size of %neg() fixups

[Richard Sandiford <rsandifo at redhat dot com>]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Richard Sandiford wrote:
> > As I understand it, the relocation field should be determined
> > by the outermost operator (%hi() in this case) and all three
> > fixups should use that size.
> 
> That's probably a too simple approach for the genaral case, since e.g. a
> 
> R_MIPS_GPREL(sym)
> R_MIPS_64(null)
> 
> sequuence is supposed to produce a 64bit addend.

Well, I'll probably missing your point here, but the sequence writes
to a 64-bit relocation field because that's what the final relocation
(R_MIPS_64) specifies.  And my patch will give it a 64-bit fixup.

> AFAICS the relocation field size in all relocations of a triple should
> be the largest one encountered there.

It sounds like you're saying that:

        R_MIPS_GPREL16
        R_MIPS_SUB
        R_MIPS_HI16

should be treated as having a 64-bit relocation field, but that's
exactly what I'm trying to avoid. ;)

The ABI says:

    The implication [...] is that a relocation type consists of two
    components.  The first component is the operation to be
    performed [...].  The second component is a specification of
    field to be relocated, which is relevant only for the first
    operation in the sequence (where it may specify an addend for
    the Elf64_Rel relocation) and the last operation in a sequence
    (where it specifies the field rewritten by the relocation).

which certainly implies to me that the middle relocation type in
a three-relocation sequence has no effect on determining the field.

I read it as saying that the final relocation type (on its own)
determines the field written.  And I think that's what matters
in terms of the fixups.

Although I haven't really looked into it yet, I suspect it might
be better to have a single fixup for the complete relocation.
But I wanted something that would be OK for 2.14.

Richard