This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/7] Regcache: Split out target regcache functionality
- From: Alan Hayward <Alan dot Hayward at arm dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, nd <nd at arm dot com>
- Date: Wed, 23 Aug 2017 12:44:31 +0000
- Subject: Re: [PATCH 0/7] Regcache: Split out target regcache functionality
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alan dot Hayward at arm dot com;
- Nodisclaimer: True
- References: <D453EE50-9381-49C4-8B02-3EA52138D387@arm.com> <86valer48e.fsf@gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> On 23 Aug 2017, at 11:02, Yao Qi <qiyaoltc@gmail.com> wrote:
>
> Alan Hayward <Alan.Hayward@arm.com> writes:
>
>> A target_regcache is a regcache connected to a target. Reads and
>> writes of register values are passed through to the target.
>> A target_regcache cannot be readonly (because this doesn't make
>> sense).
>
> At this stage, can we don't assume the readonly-ness of target_regcache?
> https://sourceware.org/ml/gdb-patches/2017-07/msg00252.html
Ok, I didn’t realise core files were treated as a target.
I need to look at the code more for this, but I couldn’t find anything in the
exisiting code that makes a core recache readonly.
If so, maybe it’s my code that needs to add this functionality.
>
>>
>> Meanwhile, a regcache (sometime referred to as a detached regcache)
>> is not connected to a target. By default it is readonly, but does
>> not have to be. In addition to the raw registers a regcache also
>> caches cooked register values. Duplicating a target_regcache will
>> always result in a detached regcache.
>>
>> Both regcache and target_regcache support the full set of raw_read,
>> raw_write, raw_collect, raw_supply, cooked_read, cooked_write
>> functions and all their variations. A user of a regache does not
>> need to treat the two types any differently - your regcache just
>> does the correct thing. For example, on a target_regcache,
>> raw_write will write to both the cache and the target, but on
>> a recache it will only write to the cache.
>>
>> With this set of patches, the regcache for the current thread (as
>> given by get_current_regcache()), is now a target_regcache, that
>> will perform exactly the same functionality as the regcache in
>> the exisiting head.
>>
>> An earlier plan for this set of patches was that the detached
>> regcache would not support raw_write, raw_collect, cooked_read,
>> cooked_write. The problem is many of the target hooks then need
>
> My suggestion was that detached regcache doesn't have
> {raw,cooked}_{read,write}_ methods, only has collect and supply methods.
> and attached one has {raw,cooked}_{read,write}_ methods.
> https://sourceware.org/ml/gdb-patches/2017-07/msg00127.html
Agreed. Typo in my description.
>
>> updating to only accept target_regcache. Many of the implementations
>> of the target hooks then call back into the regcache, causing those
>> functions in turn to be dependant on the new classes, exploding the
>> size of the patch. It then become very fiddly/confusing to maintain
>> which type of regcache is required at any point.
>
> target hooks should call regcache supply and collect methods, IMO.
>
Agreed in principle, but this is would be a large change!
It could have hidden side effects - a target that calls cooked_read might be
expecting to read a pseudo reg.
I wanted to avoid that change in this patch series.
A later set of patches could change the targets to only call supply/collect
methods. Possibly one target at a time. Once this is fixed, then the additional
methods can be removed from detached regcaches.
> --
> Yao (齐尧)