This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS embedded PIC bug.
Geoff Keating <geoffk@geoffk.org> writes:
> > In the case that triggers the error messages, because the test in the
> > code at issue succeeds, instead a _single_ instruction would be
> > output, with only a 16-bit RELOC_LO16. The code output in this case
> > is _not_ attempting to be PC-relative, as far as I can tell.
>
> That's bad. That should be fixed.
but... *stammers*
That's the problem _allowed_ by your patch to the 'o' format code for
embedded pic:
&& (mips_pic != EMBEDDED_PIC
|| offset_expr.X_op != O_subtract
|| (S_GET_SEGMENT (offset_expr.X_op_symbol)
!= now_seg)))
allows.
In the case of a typical compiler-generated lw:
$LS20:
...
lw $3,$L20-$LS20($2)
...
$L20:
it all happens to work out fine. But in the case of hand-generated
assembly, e.g.:
$LS20
...
lw $3, g1-$LS20($2)
(where g1 may be a global in another section, or who knows what), then
it doesn't work.
If it's broken for addiu with 16-bit offset (as in the la case), it's
gotta be equally broken for a 16-bit offset in the 'lw' case. 8-)
My thought is now becoming, the special 'o' format EMBEDDED_PIC check
should be nuked, and this should fall back to handling in the
load/store macro handling similar to the EMBEDDED_PIC 'la' macro
handling
> Remember, in this case we _have to_ allow a full 32-bit address,
> because the assembler doesn't know where 'g1' might end up. A typical
> case is that g1 is in the data section and this is in the text
> section, in which case they're almost never going to be less than 32k
> apart unless the program is very small and uses no libraries.
Yes, exactly! And it applies equally to 'lw'.
> I think there are only two cases:
>
> - The address is a constant and less than +/- 2^15, in which case you
> can generate one instruction; or
> - you don't know the address, or it's too big, in which case you must
> generate two.
Right.
OK, well, now at least I think I understand how the bug needs to be
fixed.
chris