Re: STUB_MOVE in elfxx-mips.c

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

cgd@broadcom.com wrote:
> At Wed, 1 Oct 2003 13:57:12 -0700, Richard Henderson wrote:
> > On Wed, Oct 01, 2003 at 11:29:36AM -0700, Ian Lance Taylor wrote:
> > > Sure.  As I said, it seemed to me at the time that `add' would never
> > > be slower than `or', so it seemed reasonable to always use `add' as
> > > the implementation of the `move' pseudo-op.  Which is what the
> > > assembler does today.  And it still seems reasonable to me.
> > 
> > Problem is, that on everyone except one chip, add sign-extends,
> > and or doesn't.  Which leads to very subtle bugs.
> 
> More generally, of course, on MIPS 32-bit add inputs that aren't
> sign-extended 32-bit values has operation that is "unpredictable."
> 
> In theory, those inputs shouldn't be generated in 32-bit programs.
> But in some (arguably broken, sure) cases it's happened in the past,
> and it can be Very Puzzling if 'move' truncates values (as it's
> allowed to do in that case).

I don't think that's actually a problem. My proposed patch only changes
the stub handling, which is about computing addresses. Anything else
than ABI_64_P will use 32bit values, and the ABI_64_P case seems to be
broken for quite some time now.

I don't want to change the implementation of 'move' without good reason.


Thiemo