CORE_ADDR representation

[Daniel Jacobowitz <dan@codesourcery.com>]

This comes up again and again, and has at least three times in the
past month with Jan's PIE patches.  Is it time for us to have opaque
arithmetic on target addresses?

My latest problem:

struct section_addr_info *
build_section_addr_info_from_objfile (const struct objfile *objfile)
{
...
  CORE_ADDR mask = CORE_ADDR_MAX;

  if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
    mask = ((CORE_ADDR) 1 << addr_bit) - 1;
...
      sap->other[i].addr = (bfd_get_section_vma (objfile->obfd, sec)
                            + objfile->section_offsets->offsets[i]) & mask;

This truncates the high bits.  MIPS sign-extends pointers, even
internally in CORE_ADDR, and this results in separate debug info files
for MIPS executables being relocated off to la-la land.  I had to add
this awful thing:

      if (bfd_get_sign_extend_vma (objfile->obfd)
          && addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT)
          && (sap->other[i].addr & ((CORE_ADDR) 1 << (addr_bit - 1))) != 0)
        sap->other[i].addr |= ~mask;

Which I'm not really proposing for inclusion, well, unless no one has
a better idea; sepdebug.exp on mips-elf currently fails without this.

For instance, should we always internally sign-extend CORE_ADDR?
Always internally zero-extend?  Having it vary by target has been a
recurring problem.

-- 
Daniel Jacobowitz
CodeSourcery