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]
Other format: [Raw text]

Re: [patch] MIPS/gas: load/store address overflow on binutils 2.14


Maciej W. Rozycki wrote:
> On Sun, 14 Sep 2003, Thiemo Seufer wrote:
> 
> > The appended version does so. It gets also rid of the bogus
> > HAVE_64_BIT_ADDRESS_CONSTANTS define, which was effectively an alias for
> > HAVE_64_BIT_GPRS, and fixes the generation of constant 64-bit addresses
> > which are not 32-bit sign extended values. I guess the latter went
> > unnoticed for so long because kernels are usually built in the 32-bit
> > compatibility space and userland is PIC code.
> 
>  I do build kernels as n64, but I haven't noticed any difference.  I don't
> think the difference would actually appear under any conditions

Your n64 kernels are still loaded in (C)KSEG0. A kernel in XKPHYS would die.

> -- can
> HAVE_64BIT_ADDRESSES be true when HAVE_64_BIT_GPRS is not? 

Of course not, and I don't see how you came to this question. :-)
I just added an "IS_SEXT_32BIT_NUM (X_add_number + 0x8000)" in that place.

> > +  /* Sign-extending 32-bit constants makes their handling easier.  */
> > +  if (! dbl)
> > +    ep->X_add_number = (((ep->X_add_number & 0xffffffff) ^ 0x80000000)
> > +			- 0x80000000);
> > +
> 
>  Do you really mean to sign-extend all constants, even if they have mixed
> bits in the high 32 ones?  I'd prefer to trigger an error or at least a
> warning in such a case.

True, it should cause as_bad().

>  As Eric wrote, a test case is desireable (to assure correct operation and
> to prevent possible future breakage) -- if you won't write one soon, I can
> do. 

I'll add the as_bad() and add a testcase tomorrow.


Thiemo


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