This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS sign extension of addresses
- From: Paul Koning <pkoning at equallogic dot com>
- To: fnf at intrinsity dot com
- Cc: binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- Date: Tue, 10 Sep 2002 12:25:07 -0400
- Subject: Re: MIPS sign extension of addresses
- References: <200209101549.g8AFnIb24401@beeville.vert.intrinsity.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