From: Yao Qi <qiyaoltc@gmail.com>
To: Alan Hayward <Alan.Hayward@arm.com>
Cc: "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org>,
nd <nd@arm.com>
Subject: Re: [RFC] Replace regcache readonly flag with detached flag
Date: Tue, 18 Jul 2017 09:47:00 -0000 [thread overview]
Message-ID: <868tjmrs9m.fsf@gmail.com> (raw)
In-Reply-To: <47F3EFED-94A1-4D7E-AA0A-AF6B9954D397@arm.com>
Alan Hayward <Alan.Hayward@arm.com> writes:
Hi Alan,
> In your regcache_1 constructor, you only NEW the cooked registers if the
> regcache is readonly.
> http://people.linaro.org/~yao.qi/gdb/doxy/regcache-split/gdb-xref/classregcache__1.html#acef3ef3bc85269cf04728901b4f28ee8
> In my version I only NEW the cooked registers in a detached register cache.
We can change regcache_1 constructor if it is wrong. I am not saying my
patches are correct, let's commit them. When I reviewed your patch, I
thought it is better to split regcache, then, I spent one day writing
the code to make sure the idea of splitting regcache makes sense. I
post the doxygen link rather than patches, because my code is still
poor, but I think the doxygen is sufficient to show the design.
>
> As I understand it, the cooked registers exist because on some architectures
> extra state needs saving in the cooked registers (code comment: "some
> architectures
> need to save/restore `cooked registers that live in memory.”).
>
> Therefore the cooked register state needs to be a property of detached
> and not of
> readonly.
>
m_registers and m_register_status are fields of detached regcache, we
can definitely save cooked register state in detached regcache.
>
> A different issue is that we treat save/restore differently.
> In your code one of the recaches has to be both read-only (checking
> via gdb_assert) and detached.
> In my code the check is that the regcache is detached or
> not. Read-only is not relevant.
It is read-only in my code, but it doesn't have to be. I don't see any
show-stoppers in the design of splitting regcache. The attributes
"detached" and "read-only" are orthogonal in design. Do you have some
comments on the overall design rather than the code details? I'll
rewrite my patches, and post them. It is unfortunate that it is hard to
review the overall design without the code.
--
Yao (齐尧)
next prev parent reply other threads:[~2017-07-18 9:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-05 14:54 Alan Hayward
2017-07-12 12:32 ` Alan Hayward
2017-07-12 21:52 ` Simon Marchi
2017-07-13 12:41 ` Alan Hayward
2017-07-13 9:04 ` Yao Qi
2017-07-14 9:21 ` Alan Hayward
2017-07-14 15:14 ` Yao Qi
2017-07-17 10:36 ` Alan Hayward
2017-07-18 9:47 ` Yao Qi [this message]
2017-07-18 11:01 ` Alan Hayward
2017-07-18 12:41 ` Maciej W. Rozycki
2017-07-18 13:09 ` Yao Qi
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=868tjmrs9m.fsf@gmail.com \
--to=qiyaoltc@gmail.com \
--cc=Alan.Hayward@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=nd@arm.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