linux-mips
[Top] [All Lists]

Re: load/store address overflow on binutils 2.14

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: load/store address overflow on binutils 2.14
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Date: Sun, 10 Aug 2003 14:08:44 +0200
Cc: linux-mips@linux-mips.org
In-reply-to: <20030809.000603.74756723.anemo@mba.ocn.ne.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20030807231518.GH3759@rembrandt.csv.ica.uni-stuttgart.de> <20030808.101102.71082885.nemoto@toshiba-tops.co.jp> <20030808030705.GJ3759@rembrandt.csv.ica.uni-stuttgart.de> <20030809.000603.74756723.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.4i
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. On mips-linux it's even worse, the result is

000000000000000b

If this is really an arch-independent problem, any (cross-)compile on
a 32bit system for 64bit BFD can be broken.


Thiemo

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