Re: Memory attributes triumphs over dcache

[jtc@redback.com (J.T. Conklin)]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:
Frank> With the memory attribute system's arrival, the independent
Frank> remotecache (dcache) engine has apparently been shut down, as
Frank> the memory attribute system doesn't provide a usable
Frank> alternative.

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.

Frank> Many targets have plain simple RAM over the regions of interest to
Frank> gdb.  Such regions appear to be hard to describe with memory
Frank> attributes: the latter appear meant more for control registers.  For
Frank> example, memory attributes artificially force transfer chunking to
Frank> 1/2/4/8 bytes.  This is a profound waste of transmit time, especially
Frank> if you make the mistake of defining the regions before downloading!
Frank> It may be sufficient to have a "width=unlimited" option available to
Frank> make it useful to cache data/insn memory.

I think you may be misunderstanding the code.  The attribute code does
not split transfers into 1/2/4/8/unspecified byte accesses.  It splits
transfers into regions, and then passes the attributes for those
regions to the lower layers.  It is up to that code to implement the
attribute in a target specific way.  

For "unspecified" width, there is no reason to change the current
behavior.  For fixed byte sizes, the to_xfer_memory function may
further split the transfer into smaller accesses, it might use a
different command (e.g. some rom monitors have separate commands for
reading/writing memory with byte/halfword/word accesses), or it might
pass additional argument(s) to the debug agent (I'm still fine tuning
extensions for the remote protocol to do this), or in might punt and
ignore the width attribute.  But if the user specified a fixed width
access, I'd like to be able to assume that he did it for a reason.

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

Frank> Also, there is no automation in defining memory attributes.  It
Frank> would make sense to define memory attributes for targets based
Frank> upon vital statistics of the active executable, for example.
Frank> Contiguous subsegments of the VMA range (.text, .data) could be
Frank> added as cacheable memory attributes fairly safely.

I can see .text and .rodata section being marked read-only and
cacheable safely by default, but not .data, since I/O devices might
DMA into the data region while the target is stopped.

Frank> Somehow generically identifying the heap & stack also would be
Frank> awesome.

What special behaviors do these regions require?

        --jtc

-- 
J.T. Conklin
RedBack Networks