From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Lance Taylor <ian@zembu.com>
To: alan@linuxcare.com.au
Cc: ac131313@cygnus.com, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [rfc] For mips, sign-extended ecoff offsets
Date: Mon, 19 Jun 2000 20:39:00 -0000
Message-id: <20000620033908.18201.qmail@daffy.airs.com>
References: <Pine.LNX.4.21.0006201128050.12273-100000@front.linuxcare.com.au>
X-SW-Source: 2000-06/msg00397.html

   Date: Tue, 20 Jun 2000 11:50:26 +1000 (EST)
   From: Alan Modra <alan@linuxcare.com.au>

   > > I'm worried about what happens if things like PDR.adr get changed from
   > > 0xa0000000 to 0xffffffffa0000000.
   > 
   > Thats why I'm asking :-) Remember though, on the MIPS platform, if
   > ``PDR.adr'' is an address then, the canonical form of the value
   > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. 
   > GDB and BFD have, for too many years, been bribed and cajoled into
   > perpetuated the lie that MIPS doesn't sign extend addresses.   GDB's now
   > decided to come clean on this matter (and purge an amazing amount of
   > bogus code :-).


   > I guess the question for BFD people is, is this the correct approach to
   > fixing this bug?

   I'd like to hear Ian's comments on this before you check it in.

This is all due to a long-ago decision to ship support for a 64-bit
MIPS chip using a 32-bit MIPS target.  I think that sign extending
pdr.ADR is probably right, since that is how 32 bit addresses are
treated by the relocation routines.  But the real fix is to use a
64-bit MIPS target.

Ian