This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 08/02/2012 08:17 AM, Yao Qi wrote:
> Hi,
> When I am modifying 'target_changed' observer, I don't understand
> why we attach regcache_observer_target_changed to 'target_changed'
> observer, and invalidates all regcache.  'target_changed' observer
> is notified in valops.c:value_assign, before that, register is
> modified by calling either gdbarch_value_to_register or
> put_frame_register_bytes.  Looks like regcache is in a good state,
> why do we have to invalidate them?
> 
> The code that invalidates all regcache was added by this patch,
> 
>   Multiplexed registers and invalidating the register cache
>   http://sourceware.org/ml/gdb-patches/2004-04/msg00282.html
> 
> The author (Orjan) tried to support "changing the bank select register
> changes the contents (and meaning) for a whole set of other registers."
> The requirement is quite specific to Orjan's own port, so the better
> solution is to attach a function which invalidates all regcache in
> Orjan's backend, instead of doing it in target-independent part.

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 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.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]