Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: David Taylor <taylor@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] regcache.c (register_fetched) + related changes
Date: Wed, 28 Feb 2001 13:14:00 -0000	[thread overview]
Message-ID: <200102282113.QAA18390@texas.cygnus.com> (raw)

    From: Andrew Cagney <ac131313@cygnus.com>
    Date: Tue, 27 Feb 2001 20:38:30 -0500

    David Taylor wrote:

    > I propose that we:
    > 
    > . add register_fetched

    David,

    The functionality of register_fetched() overlaps with
    set_register_cached() and supply_register().  Rather than add a
    redundant method, could an existing interface be used or the current
    interfaces rationalized slightly?

Andrew,

Supply register does more than register_fetched; register_fetched only
affects register_valid -- the register must have been supplied via
some other method.

set_register_cached is -- with one exception -- only used within
regcache.c.  The one exception is remote.c (remote_fetch_registers).

I feel that a function should be created (register_unavailable?) and
the call in remote.c to set_register_cached replaced with that call.
Then set_register_cached should be made static.

To call set_register_cached, you have to know what the meanings are of
the various possible values of register_valid.  This is knowledge that
shouldn't really exist outside of regcache.c.

    Keep in mind that the long term goal is to tighten regcache's interface
    signficantly.  That is, eliminate register_valid[], registers[] and
    possibly even set_register_cached() replacing them with a small set of
    functions such as:
	    supply_register()
	    supply_unavailable_register()
    If you are thinking of proposing further changes then you may want to
    keep that in mind.

My change advances the goal of eliminating register_valid!  It reduces
significantly the number of files that even know that register_valid
exists!  Outside of regcache.c, only two files would reference it (for
a total of three references).  Those two files could also have their
references to it removed with a little bit more work.

    With regard to regcache.h, yes the two clash.  It both moves code around
    and changes the set_register_cached() interface.  If anything regcache.h
    makes life easier because it is finally clear what the regcache
    interfaces really are.

	    Andrew

What change is this that you are referring to?  The message with subject

    [rfc] Re-merged regcache.h patch

that you posted after the above message?  I assume not, but if so...

. It does not move around code within regcache.c.  It adds a comment
  to regcache.c.  I don't see that as a conflict with my patch.

. Yes, it adds a new header file regcache.h.  A header file that is
  long overdue.  But, that does not affect the bulk of my patch.  It
  means that my one line change to gdbcore.h becomes instead a one
  line change to regcache.h.  Not a big deal -- I can change this
  easily enough.

. The posted patch does not change the set_register_cached interface.
  It does add a comment concerning the interface that conflicts with
  reality:

  +/* Character array containing the current state of each register
  +   (unavailable<0, valid=0, invalid>0). */

  but that is a problem with that patch, not with mine.

  [Current reality is: unavailable<0, invalid=0, valid>0.]

David


             reply	other threads:[~2001-02-28 13:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-28 13:14 David Taylor [this message]
2001-02-28 15:17 ` Andrew Cagney
2001-02-28 16:01   ` Andrew Cagney
2001-02-28 18:27   ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2001-03-01 16:59 David Taylor
2001-03-02  9:06 ` Andrew Cagney
2001-03-02 11:49 ` Andrew Cagney
2001-03-13  8:52   ` Andrew Cagney
2001-03-01 10:34 David Taylor
2001-03-01 14:07 ` Andrew Cagney
2001-02-27 15:27 David Taylor
2001-02-27 14:25 David Taylor
2001-02-27 14:48 ` Michael Snyder
2001-02-27 15:21 ` Andrew Cagney
2001-02-27 17:40 ` Andrew Cagney

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=200102282113.QAA18390@texas.cygnus.com \
    --to=taylor@cygnus.com \
    --cc=ac131313@cygnus.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