From: Alan Hayward <Alan.Hayward@arm.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
nd <nd@arm.com>
Subject: Re: [PATCH 1/7] Regcache: Subclass ptid functionality to target_regcache
Date: Wed, 23 Aug 2017 13:24:00 -0000 [thread overview]
Message-ID: <D4FCB56A-1111-4412-84D1-1111A5E51CBD@arm.com> (raw)
In-Reply-To: <86mv6qr2u9.fsf@gmail.com>
> On 23 Aug 2017, at 11:33, Yao Qi <qiyaoltc@gmail.com> wrote:
>
> Alan Hayward <Alan.Hayward@arm.com> writes:
>
>> All ptid related functions are moved to target_regcache.
>>
>
> What is the rationale of this change? The regcache is per-thread, even
> it is disconnected from target.
In the existing code, when calling regcache_dup / copy constructor,
ptid of the new recache is always set to -1.
In the save / restore functions the ptid is not updated.
The regcache.c functions which read/write the ptid only do that using the
target connected regcaches.
Calling regcache_get_ptid on a readonly regcache will result in an assert
firing.
Therefore, in existing code, a readonly recache will always have a ptid
of -1. In the new code this property now becomes part of a detached
regcache.
However.....
>
>> A regcache retains the ptid () method, which always returns -1.
>
> ptid_t (-1) is minus_one_ptid, which has a special meaning.
Agreed. The existing code already treats -1 tpid to mean different things.
I’ve been thinking about this again.
regcache_get_ptid asserts if ptid is -1. Therefore ptid() should also
assert on a detached recache ?
With this change, a detached recache would never have a ptid.
I think that simplifies the code too.
>
>> This ensures users can always test if a regcache is attached to a
>> target, without needing to know if it is a target_regcache.
>
> When do we need such test ("if a regcache is attached to a target”)?
We don’t. I’m happy to drop this statement.
If we do need to add a test, there will probably be a better way of doing it.
>
> --
> Yao (齐尧)
prev parent reply other threads:[~2017-08-23 13:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6AAAA989-5B31-4E54-963C-57F2B7452BD7@arm.com>
2017-08-23 10:33 ` Yao Qi
2017-08-23 13:24 ` Alan Hayward [this message]
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=D4FCB56A-1111-4412-84D1-1111A5E51CBD@arm.com \
--to=alan.hayward@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=nd@arm.com \
--cc=qiyaoltc@gmail.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