MIPS sign extension of addresses

[Fred Fish <fnf at intrinsity dot com>]

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

For example, using the latest development versions of gcc, gdb,
binutils, and newlib (latest as of a week ago anyway), the standard
mipsisa32-elf configured toolchain gets the following results just for
"mips-sim-idt32/-msoft-float", excluding the gdb.mi, gdb.gdbtk, and
gdb.threads tests:

  # of expected passes            5689
  # of unexpected failures        281
  # of expected failures          29
  # of unresolved testcases       41
  # of untested testcases         3
  # of unsupported tests          15

After doing some work on gdb and the testsuite over the weekend, my
results for the mips-elf toolchain are:

  # of expected passes            6126
  # of unexpected failures        91
  # of expected failures          39
  # of unresolved testcases       28
  # of untested testcases         3
  # of unsupported tests          6
  # of unexpected successes       1

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

I suppose this might make more sense to me if I either had more
historical knowledge about why it does this, or if bfd_vma/CORE_ADDR
were signed types.

The trigger for this behavior in BFD is the field called
sign_extend_vma in the elf backend data, which apparently is only set
by elf32-mips.c, elf32-sh64.c, and elfn32-mips.c.  This special
treatment for mips seems to also be why we need the regcache to
support a read_signed_register call that is only used in mips-tdep.c.

There are also some ADDR_BITS_REMOVE macros used in mips-tdep.c that
one might think would be there to strip the high bits but really don't
since that macro invokes mips_mask_address_p() which tests
mask_address_var which defaults to AUTO_BOOLEAN_AUTO which uses
MIPS_DEFAULT_MASK_ADDRESS_P which checks the multiarch value of
default_mask_address_p which seems to be set to zero everywhere.

Is all of this just internal gdb handwaving that can be changed/fixed
or are there external reasons for all this sign extending followed by
selective discarding/ignoring of the extended bits?  Are there files
that will break or hardware that will misbehave if BFD stops doing
this sign extension?

After getting a little feedback from some private email exchanges
containing substantially the same info as above, I've modified my
mental picture of this process to think of it as a simple address
translation scheme.  I.E. when running a 32 bit binary in a 64 bit
address space, effectively the 32 bit address space is split in half,
with the lower half (0x00000000-0x7FFFFFFF) mapped to the bottom of
the 64 bit space and the upper half (0x80000000-0xFFFFFFFF) mapped to
the top of the 64 bit space.
 
I suppose this makes sense in a toolchain where you want the same gdb
to be able to handle both 64 and 32 bit mips.  I'm fairly unfamiliar
with all the different possible mips configurations, but perhaps it
would be less confusing if there was one that was strictly 32 bit
internally, much like when configuring and building a native
i686-pc-linux-gnu toolchain uses an "unsigned long int" type for
bfd_vma instead of an "unsigned long long int".

-Fred