This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
CORE_ADDR representation
- From: Daniel Jacobowitz <dan at codesourcery dot com>
- To: gdb at sourceware dot org
- Date: Wed, 17 Feb 2010 23:44:19 -0500
- Subject: CORE_ADDR representation
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