[rfc] For mips, sign-extended ecoff offsets

Ralf Baechle ralf@oss.sgi.com
Sun Jun 25 14:13:00 GMT 2000

On Mon, Jun 19, 2000 at 08:41:02PM -0700, Ian Lance Taylor wrote:

>    > 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).
> I think the real reason this happens is historical--because we didn't
> have a 64-bit MIPS format when we started supporting 64-bit MIPS
> chips.  I don't think there is any particularly legitimate reason to
> use a 32-bit format for a 64-bit chip.

We do that for Linux/MIPS64.  Originally I came up with this due to the
incredible brokeness of ld for 64-bit MIPS ELF.  It allows us to generate
64-bit code that is more compact than standard 64-bit code because dla get
expanded to only 2 instructions like in 32-bit code.  All it takes is
proper placement of the code into the 32-bit address space.  We still
have kept the advantages of 64-bit code.


More information about the Gdb-patches mailing list