Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Don't attach to 'target_changed' observer in regcache
Date: Thu, 02 Aug 2012 14:46:00 -0000	[thread overview]
Message-ID: <501A92B5.4070302@redhat.com> (raw)
In-Reply-To: <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


  reply	other threads:[~2012-08-02 14:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-02  7:17 Yao Qi
2012-08-02 14:46 ` Pedro Alves [this message]
2012-08-02 15:40   ` Yao Qi
2012-08-08 17:54 ` Mark Kettenis
2012-08-09  3:11   ` Yao Qi
2012-08-09  8:12     ` Mark Kettenis
2012-08-09  8:37       ` Yao Qi
2012-08-21 19:39         ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=501A92B5.4070302@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox