From: Joel Brobecker <brobecker@gnat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [commit/multiarch/hpux] set addr_bits_remove gdbarch method
Date: Fri, 05 Dec 2003 02:13:00 -0000 [thread overview]
Message-ID: <20031205021321.GM1652@gnat.com> (raw)
In-Reply-To: <3F3A85FB.5040502@redhat.com>
[Coming back to an old thread. Was it that long ago already? Sigh...]
On Wed, Aug 13, 2003 at 02:39:55PM -0400, Andrew Cagney wrote:
> Yep: Consider merging SMASH_TEXT_ADDRESS with ADDR_BITS_REMOVE
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=333
>
> Any one got a preference over which one goes? Otherwize, Joel, with
> HP/UX cleaned up, it should either way be pretty obvious.
I looked a bit at the code, and I have a small preference of
ADDR_BITS_REMOVE over SMASH_TEXT_ADDRESS. In addition, the only
2 targets that set smash_text_address also define addr_bits_remove
(hppa-tdep.c and arm-tdep.c). So it looked like there would be an easy
transition:
- s/SMASH_TEXT_ADDRESS/ADDR_BITS_REMOVE/g
This should be a noop if we assume:
SMASH_TEXT_ADDRESS <=> ADDR_BITS_REMOVE
- Remove the two calls to gdb_arch_set_smash_text_address
- Delete the SMASH_TEXT_ADDRESS gdbarch method
Unfortunately, It doesn't look like these two methods are that
identical, at least in the case of arm:
static CORE_ADDR
arm_addr_bits_remove (CORE_ADDR val)
{
if (arm_apcs_32)
return (val & (arm_pc_is_thumb (val) ? 0xfffffffe : 0xfffffffc));
else
return (val & 0x03fffffc);
}
/* When reading symbols, we need to zap the low bit of the address,
which may be set to 1 for Thumb functions. */
static CORE_ADDR
arm_smash_text_address (CORE_ADDR val)
{
return val & ~1;
}
SMASH_TEXT_ADDRESS is used in coffread, dbxread, dwarfread, elfread,
and somread.
ADDR_BITS_REMOVE is used in arm*.c, buildsym, infrun, monitor, printcmd,
regcache, remote-mips, values.c (I have deliberately excluded mips-tdep,
remote-mips, s390-tdep, and sh64-tdep since these can not be covered
while the arm gdbarch is in effect).
Looks like the merge is not going to be that obvious... We need to see
if we can merge arm_addr_bits_remove and arm_smash_text_address first...
--
Joel
next prev parent reply other threads:[~2003-12-05 2:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-13 17:19 Joel Brobecker
2003-08-13 18:40 ` Andrew Cagney
2003-12-05 2:13 ` Joel Brobecker [this message]
2003-12-05 2:16 ` Daniel Jacobowitz
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=20031205021321.GM1652@gnat.com \
--to=brobecker@gnat.com \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/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