This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CORE_ADDR representation


> Date: Wed, 17 Feb 2010 23:44:19 -0500
> From: 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?

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]