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