This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: STUB_MOVE in elfxx-mips.c
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