Re: [rfc] For mips, sign-extended ecoff offsets

[Geoff Keating <geoffk@cygnus.com>]

> From: Ulf Carlsson <ulfc@calypso.engr.sgi.com>
> Date: Mon, 19 Jun 2000 20:48:56 -0700 (PDT)
> 
>  > > On a 64-bit MIPS processor 32-bit addresses are of course sign
>  > > extended, but this shouldn't concern the 32-bit BFD backend for MIPS
>  > > in any way.  Whether we sign extend the addresses or not shouldn't
>  > > make any difference except in our internal representation of the
>  > > bfd_vma.  I may be wrong though!
>  > 
>  > The 64-bit MIPS machines often use the 32-bit ELF format, typically
>  > because they have 32-bit memory addresses (I forget whether trying to
>  > access 0x0000000087654321 gives you 0xffffffff87654321 or a trap).
> 
> We always have 0x87654321 in the 32-bit ELF file.  It probably doesn't
> matter what our internal representation is since we'll drop the upper
> 32 bits when we write the ELF file in either case and the address will
> be properly sign extended again when the ELF file is loaded.

A similar argument was used originally to justify not forcing BFD to
do the right thing.

An example where it does matter is when you try to work out whether
a 32-bit pc-relative operand can hold the offset from 0x10000000 to
0xA0000000, or whether there should be overflow.

In GDB, it matters whenever you are comparing a value in a register to
an address in the object file.
-- 
- Geoffrey Keating <geoffk@cygnus.com>