Re: MIPS sign extension of addresses

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Fred" == Fred Fish <fnf@intrinsity.com> writes:

 Fred> I'm currently working on a mipsisa32-elf based toolchain and
 Fred> was concerned about the number of failures in the gdb
 Fred> testsuite.

 Fred> ...Most of the problems I fixed had to do with the fact that BFD
 Fred> takes the 32 bit unsigned addresses from object and executable
 Fred> files, sign extends them, and then stores the result as a
 Fred> bfd_vma, which is an unsigned 64 bit type (unsigned long long).
 Fred> For example, the unsigned 32 bit address 0x80020004 becomes an
 Fred> unsigned 64 bit bfd_vma/CORE_ADDR of 0xffffffff80020004.  The
 Fred> bfd_vma type is used to define gdb's CORE_ADDR types.

 Fred> ...After getting a little feedback from some private email
 Fred> exchanges containing substantially the same info as above, I've
 Fred> modified my mental picture of this process to think of it as a
 Fred> simple address translation scheme.  I.E. when running a 32 bit
 Fred> binary in a 64 bit address space, effectively the 32 bit
 Fred> address space is split in half, with the lower half
 Fred> (0x00000000-0x7FFFFFFF) mapped to the bottom of the 64 bit
 Fred> space and the upper half (0x80000000-0xFFFFFFFF) mapped to the
 Fred> top of the 64 bit space.

That sounds right.  I looked in the MIPS Inc. reference (MIPS64
architecture, part 3, privileged architecture,
MD00091-2B-MIPS64PRA-AFP-00.95.pdf) and it shows exactly the picture
you describe.  For example, kseg0 starts at 0xffffffff80000000 in 64
bit addressing.

   paul