This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Don't attach to 'target_changed' observer in regcache
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 02 Aug 2012 15:46:13 +0100
- Subject: Re: [PATCH] Don't attach to 'target_changed' observer in regcache
- References: <1343891847-16554-1-git-send-email-yao@codesourcery.com>
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