This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] regcache.c (register_fetched) + related changes
- To: David Taylor <taylor at cygnus dot com>, gdb-patches at sources dot redhat dot com, Michael Snyder <msnyder at cygnus dot com>
- Subject: Re: [RFA] regcache.c (register_fetched) + related changes
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 28 Feb 2001 21:25:16 -0500
- References: <200102282113.QAA18390@texas.cygnus.com> <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