Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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