linux-mips
[Top] [All Lists]

Re: load/store address overflow on binutils 2.14

To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: Re: load/store address overflow on binutils 2.14
From: Chip Coldwell <coldwell@frank.harvard.edu>
Date: Sun, 10 Aug 2003 10:36:51 -0400 (EDT)
Cc: linux-mips@linux-mips.org
In-reply-to: <20030810120844.GB22977@rembrandt.csv.ica.uni-stuttgart.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
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"      \<
                              (@)/(@) 
-------------------------------------


<Prev in Thread] Current Thread [Next in Thread>