Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: David Taylor <taylor@cygnus.com>,
	gdb-patches@sources.redhat.com,
	Michael Snyder <msnyder@cygnus.com>
Subject: Re: [RFA] regcache.c (register_fetched) + related changes
Date: Wed, 28 Feb 2001 18:27:00 -0000	[thread overview]
Message-ID: <3A9DB30C.62C07D74@cygnus.com> (raw)
In-Reply-To: <3A9D8655.C57F3DB6@cygnus.com>

Andrew Cagney wrote:

> Yes.  My suggestion, hinted at in the last e-mail, would be to combine
> the two disjoint operations:
> 
>         supply_register(....);
>         set_register_cache(..., -1)
> 
> into an atomic cache transaction:
> 
>         supply_unavailable_register(....)

PS/2:  The comment on supply_register() in regcache.c reads:

   [....]
   If VAL is a NULL pointer, then it's probably an unsupported register.
   We just set its value to all zeros.  We might want to record this
   fact, and report it to the users of read_register and friends.  */

Nothing is recorded.  The register is simply set to zero.

Checking the target code, this ``feature'' is used a lot (eg
alphabsd-nat.c):

      if (CANNOT_FETCH_REGISTER (i))
        supply_register (i, NULL);
      else
        supply_register (i, (char *) &gregsetp->r_regs[i]);

GDB really should record this cache state giving:

	valid
	unavailable
	invalid
	unsupported

Alternativly, the states unavailable and unsupported could be merged.

remote.c, which puts the cache into ``unavailable'' state, also writes
zeros into the register.

Thoughts? Especially from the people that added introspect support.

	Andrew


  parent reply	other threads:[~2001-02-28 18:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-28 13:14 David Taylor
2001-02-28 15:17 ` Andrew Cagney
2001-02-28 16:01   ` Andrew Cagney
2001-02-28 18:27   ` Andrew Cagney [this message]
  -- 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=3A9DB30C.62C07D74@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@cygnus.com \
    --cc=taylor@cygnus.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