CORE_ADDR representation

Daniel Jacobowitz dan@codesourcery.com
Thu Feb 18 04:44:00 GMT 2010


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



More information about the Gdb mailing list