Re: [PATCH 3/5] set/show code-cache

[Doug Evans <dje at google dot com>]

On Fri, Oct 25, 2013 at 7:34 AM, Yao Qi <yao@codesourcery.com> wrote:
> On 10/25/2013 03:47 PM, Doug Evans wrote:
>>
>> While perhaps it usually won't be a problem (*1), it's odd to have two
>> caches.
>
>
> At the very beginning, I use single dcache for both stack access and code
> access.  However, it is odd that command "set stack-cache off" invalidates
> code caches, so I decide to add a new cache dedicated to code access.

If it's just that "set stack-cache off" flushed the cache (as opposed
to disabling/breaking all future use) I think that's ok.  How often
will it get turned on and off?

>> If I do x/10x $addr and then x/10i $addr will both caches get populated?
>
>
> No, "x/10i $addr" gets code cache populated, while "x/10x $addr" doesn't get
> "general" or "stack" cache populated, unless I set memory attribute cache
> for this area.

Sorry, I left the assumption that caching is turned on via memory
attributes as implicit.
To be explicit: "If I turn on caching by memory attributes, and then
do x/10x $addr and then x/10i $addr, will both caches get populated?"
:)

[Of course, if caching of the addresses in question is turned on by
memory attributes then one doesn't need special code caching, but I'm
not arguing against special support for code caching.]

>> [Will there be latent bugs due to "storing the same thing twice"?
>> (which has been a source of bugs in gdb)  Plus there's the extra
>> complexity of keeping both in sync.]
>
>
> "Storing the same thing twice" may introduce bugs, but "store two things
> together" is not good either :).

It's still the same data.

> The code keeping caches in sync is localized, and probably we can move them
> into a new file target-cache.c.  I don't see too much complexity here and
> the disassembly is sped up, so it is worth doing it, IMO.

It still seems to me to be an unnecessary complexity.