Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: dan@codesourcery.com
Cc: gdb@sourceware.org
Subject: Re: CORE_ADDR representation
Date: Thu, 18 Feb 2010 10:18:00 -0000	[thread overview]
Message-ID: <201002181017.o1IAHDdS030942@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <20100218044416.GA19485@caradoc.them.org> (message from Daniel 	Jacobowitz on Wed, 17 Feb 2010 23:44:19 -0500)

> 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.


  parent reply	other threads:[~2010-02-18 10:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-18  4:44 Daniel Jacobowitz
2010-02-18  5:42 ` Stan Shebs
2010-02-18 14:11   ` Daniel Jacobowitz
2010-02-18 23:04     ` Tom Tromey
2010-02-18 10:18 ` Mark Kettenis [this message]
2010-02-18 13:43   ` Daniel Jacobowitz
2010-02-19 19:27     ` Tom Tromey
2010-02-18 10:34 ` Jan Kratochvil
2010-02-18 13:41   ` Daniel Jacobowitz
2010-02-18 13:53     ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201002181017.o1IAHDdS030942@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=dan@codesourcery.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox