[rfc] For mips, sign-extended ecoff offsets
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