Fix MIPS ELF64 problem with .gpword/.8byte combinations

[Richard Sandiford]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Richard Sandiford wrote:
> [snip]
>> >> + macro_read_relocs (va_list *args, bfd_reloc_code_real_type *r)
>> >> + {
>> >> +   int i, next;
>> >> + 
>> >> +   next = va_arg (*args, int);
>> >> +   if (next >= 0)
>> >> +     r[0] = (bfd_reloc_code_real_type) next;
>> >> +   else
>> >> +     for (i = 0; i < 3; i++)
>> >> +       r[i] = (bfd_reloc_code_real_type) va_arg (*args, int);
>> >> + }
>> >
>> > AFAICS this is likely to cause breakage if we have to support combined
>> > dual relocs.
>> 
>> Why?  Just pass BFD_RELOC_UNUSED as the third code.
>
> And if this isn't done, macro_read_relocs has no way to find it out and
> complain about it. 

Well of course it hasn't ;)  But the same's true for any varargs function.
E.g., macro_build() has no way of knowing whether you remembered to pass
a register for an 'r' field, or whatever.

To be honest, your patch looks very much like over-engineering to me.
It makes the code longer and more complex, it doesn't fix a bug, and it
has no known user.  I just don't see the point.

Obviously we could revisit this later in the (IMO very unlikely) event
that someone adds a new macro that uses two-code composite relocations
(and if that someone finds it more convenient to use -2).  But until that
happens, this just seems like obfuscation.

OTOH, you're the maintainer, not me, so my opinion doesn't really count ;)

Richard