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>
- Subject: Re: [RFA] regcache.c (register_fetched) + related changes
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 02 Mar 2001 12:03:33 -0500
- Cc: gdb-patches at sources dot redhat dot com
- References: <200103020058.TAA18595@texas.cygnus.com>
> Can you give an example of where this is happening? I'm currently aware
> of two cases:
>
> [0 .. NUM_REGS)
> where supply_register() should be used
>
> Not always. See below.
>
> [NUM_REGS .. NUM_REGS + PSEUDO_NUM_REGS)
> I suspect your case.
>
> I *clear* in the [NUM_REGS, NUM_REGS+PSEUDO_NUM_REGS) range and *set*
> in the [0, NUM_REGS) range.
The code that sets the valid bit in the range [0, NUM_REGS) should be
doing so using either of the functions:
supply_register() - target side
or write_register_gen() - core-gdb side
if it isn't it is doing something un-documented and so, in my opinion,
should use a function that makes the use of that un-documented behavour
very clear.
Hence, in your case, I think your code really should be using a function
called something like deprecated_raw_register_fetched().
If I commit a change that replaces register_valid[] with the pair:
deprecated_raw_register_fetched()
pseudo_register_fetched()
will this allow your existing code to work?
Looking to the future, when (not if) the frame code is re-vamped to have
register values bound to a frame, will it be possible to use that
mechanism to implement what you're trying to do how using the regcache?
Andrew