Re: Register Cache.

[Fernando Nasser <fnasser at redhat dot com>]

This would be a serious problem on targets that have access to Control
Registers.   However, I vaguely remember our register cache being a
"write-through" cache, i.e., registers are written to the cache AND to
the actual register (it worked like that on the source code at some
point last year -- there are people using this right now).  I wonder if
this behavior was changed.

The only complain I got from users is that some hardware registers do
not keep the value that are written to them (some of the bits you may
have written to are R/O or you write to a bit to reset it and it is read
as zero afterwards etc.).  As GDB caches the value it has written,
subsequent reads do not reflect the actual register value until you run
the target (a stepi will do).  The solution proposed (never implemented)
was to add a user command to flush the register cache.  In the GUI case,
on user request, the GUI would reread the values after doing that.  This
would prevent the user to do a "stepi" (sometimes not desirable).

Fernando



Andrew Cagney wrote:
> 
> Just FYI,
> 
> I'm letting this e-mail slip off my desk and onto the floor.  Someone
> will eventually re-visit the idea (since it is very real).?
> 
>         Andrew
> 
>   ------------------------------------------------------------------------
> 
> Subject: Register Cache.
> Date: Wed, 30 Aug 2000 10:47:06 +1000
> From: Steven Johnson <sbjohnson@ozemail.com.au>
> To: gdb@sources.redhat.com
> References: <8AE4B526B977D411841F00A0CC334020052C28@cuz-exchange.sdesigns.net>
> 
> GDB caches it's register reads. ie, it will only read a register once, and
> will only write a register if it thinks the value has changed.
> 
> For Example:
> 
> set $myreg=0x12345678     <-- Results in GDB Actually changing the register.
> set $myreg=0x12345678     <-- Filtered by GDB and doesnt set register.
> 
> Now this seems fine on the surface, but there are many registers that
> the act of writing is sometimes more important than the data (like say a
> watchdog reset register). You may need to write the same value multiple times.
> 
> I Can find no way of forcing GDB to not cache its register accesses (dcache
> also has this problem, but it also has a solution) does anyone know of a way to
> force GDB to either always update registers and read registers and not cache
> them, or of a way to force GDB to set it's status of these registers as unknown
> (and hence making it update from the register).
> 
> Ive spent all day hunting through the code ("Using the source" as some would
> say) but i'm damned if I can find anything. So I am attempting to introduce my
> own solution. But obviously I may have missed something.
> 
> Steven Johnson
> 
>   ------------------------------------------------------------------------
> 
> Subject: Re: Register Cache.
> Date: Thu, 31 Aug 2000 14:27:24 +1000
> From: Steven Johnson <sbjohnson@ozemail.com.au>
> To: gdb@sources.redhat.com
> References: <8AE4B526B977D411841F00A0CC334020052C28@cuz-exchange.sdesigns.net> <39AC598A.DFAF67E9@ozemail.com.au>
> 
> I Want to change the way GDB Caches Registers by doing the following:
> 
> 1. Add a Cache Type entry so that each register can be set (via a gdb command)
> to be read cached, write cached or no cache. By default it would be read/write
> cache enabled as is the case now.
> 
> 2. Add a command to flush GDB's knowledge of the cache.
> 
> My Questions are:
> 
> 1. Does anyone have any input they would like to add to this?
> 2. What sort of command should they be maintenance, data or set commands.
> 
> I Would like to have commands like this:
> set register-cache $r5 read
> set register-cache $r5 write
> set register-cache $r5 rw
> set register-cache $r5 disabled
> 
> and another command
> 
> maintenance register-cache flush
> 
> This raises another question:
> 
> 3. How do i look up the $r5 in the command and turn it into a register number?
> 
> I tried finding the code the interprets:
> set $r5=0
> 
> to see how it did it, but it's obscure and I couldn't find it.
> 
> Steven Johnson.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9