This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]