Re: load/store address overflow on binutils 2.14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 10 Aug 2003, Thiemo Seufer wrote:

> Atsushi Nemoto wrote:
> > >>>>> On Fri, 8 Aug 2003 05:07:05 +0200, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> said:
> > >> The b.S is just one line "lw $2, 0x80000000".
> > Thiemo> Using 0xffffffff80000000 is a really ugly workaround for it.
> > Thiemo> Seems like the constant isn't properly sign-extended inernally
> > Thiemo> by the assembler.
> > 
> > Yes the workaround works.  But I modified binutils (just remove the
> > checking code) instead of changing many constant definitions in my
> > programs.  For now it is enough for me.  Thank you.
> 
> It is probably not a real binutils bug, but related to gcc mishandling
> 'unsigned long long'. The simple testcase
> 
> int main(void)
> {
>         unsigned long long a = 0;
> 
>         printf("%016x\n", ~a);
> 
>         return 0;
> }
> 
> outputs
> 
> 00000000ffffffff
> 
> on my i386-linux system.

Strangely, this is actually "correct" behavior.  Arguments on
variable-length argument lists are implicitly "promoted" to unsigned
int at the widest.  See K&R 2nd ed. A6.1 and A7.3.2.  Things may have
changed with C99, but this would have been expected behavior for ANSI
C, and strange results were to be had when "long int" was wider than
"int" and was passed on a variable-length argument list.

Chip

-- 
Charles  M. "Chip" Coldwell      __o
"Turn on, log in, tune out"      \<
                              (@)/(@) 
-------------------------------------



[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux