This is the mail archive of the
mailing list for the GDB project.
Re: CORE_ADDR representation
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: dan at codesourcery dot com
- Cc: gdb at sourceware dot org
- Date: Thu, 18 Feb 2010 11:17:14 +0100 (CET)
- Subject: Re: CORE_ADDR representation
- References: <20100218044416.GA19485@caradoc.them.org>
> Date: Wed, 17 Feb 2010 23:44:19 -0500
> From: Daniel Jacobowitz <email@example.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?
I'm no terribly excited by having opaque arithmetic. I fear that it
will make the code significantly harder to read :(.
> 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.
Perhaps we should introduce a function to "normalize" addresses (mask
off high-bits or sign extend) that we call in places that need it?
It'd be a no-op for a N-bit debugger debugging an N-bit target, so
you'd be able to call it unconditionally. That should clear away
quite a bit of clutter.
> For instance, should we always internally sign-extend CORE_ADDR?
> Always internally zero-extend? Having it vary by target has been a
> recurring problem.
The problem is that BFD may still give you sign-extended addresses.
So you'd have to normalize them before sticking them into a CORE_ADDR.