Re: Memory attributes triumphs over dcache

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

jtc wrote:

: That wasn't the intention.  Note that you can specify whether a region
: is cached.  While the "default" attribute (used for accesses outside a
: defined region) has host side caching disabled, I don't think this is
: any different from before when caching was disabled globally.

True, though I am more intersted in the "enabled globally" case, when
the cache is used for performance improvement.


: [...]
: I think you may be misunderstanding the code.  [...]

Yeah, possibly.  I don't actually see any target looking at the
MEM_WIDTH_* fields!  (BTW, mem_command fails to initialize the new
mem_attrib struct rigorously.  It should assign defaults to all the
optional flags explicitly.)

What got me worried is the effect of defining a memory region (with
caching but no other flags), then doing a "target remote" download.
It proceeded one byte at a time - yuck!  If some combination of the
dcache and memattr system is at fault, this still needs to be
improved.


: [...]
: Note that dcache itself chunks things into cache line sized accesses.

(... which is too small when dealing with large cacheable regions,
talking across a latency-bound protocol ...)


: Frank> Also, there is no automation in defining memory attributes.  [...]
: 
: I can see .text and .rodata section being marked read-only and
: cacheable safely by default, 

If .text is read-only, the breakpoint instruction insertion can't work.
(You're talking "read-write"/"read-only" from the point of view of the
debugger, not of the inferior program!)


: but not .data, since I/O devices might
: DMA into the data region while the target is stopped.

I suppose so, if this is really that frequent or likely an occurrence.
If it is infrequent, then making the default the opposite makes sense.


: Frank> Somehow generically identifying the heap & stack also would be
: Frank> awesome.
: 
: What special behaviors do these regions require?

Primarily, cachebility.


- FChE

PGP signature