Re: [PATCH] Don't attach to 'target_changed' observer in regcache

[Yao Qi <yao@codesourcery.com>]

On Thursday, August 02, 2012 03:46:13 PM Pedro Alves wrote:
> Really not sure about this.  There were also comments from Dan and Cagney
> on that thread, that point at need for this being not that uncommon.
> 
> E.g. Dan wrote:
> > I've been meaning to do this for a long time.  For instance, there is a
> > writeable register on PowerPC targets which has some read-only bits.
> > Right now, if you set it to an arbitrary value and then print it you'll
> > get the value GDB wrote - not the value that was actually accepted into
> > the register.
> > 
> > Andrew convinced me that the performance cost associated with this
> > would be small in practice.
> 

I red Dan's comment, but I thought it is uncommon :)

> I think you get to argue against the whole picture, not just Orjan's
> port, although I think we'd also need a plan to address the original
> issue in some other way.  E.g., I can picture that gdb might not even
> have any knowledge of such registers (so no way to hardcode when-to-flush
> in the backend), as they may have been included as part of a target
> description, in addition to core registers.

It is a good idea to extend target description for the attributes of each 
register, for example, a certain bit of a register is read-only.  However, 
target description can't handle Orjan's requirement (changing the bank select 
register changes the contents for a whole set of other registers.).

My original thought is to extend observer 'target_changed' to pass more 
parameters, such as 'register number', and backend registers its own hook to 
'target_changed' observer, and takes right actions for the "interesting" 
register changes.  Maybe we can do this via gdbarch hook.

THe problem is clear, but its description is not very precise.  I don't have a 
solid plan so far.

-- 
Yao (齐尧)