From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: fche@redhat.com (Frank Ch. Eigler) Cc: gdb@sources.redhat.com Subject: Re: Memory attributes triumphs over dcache Date: Tue, 03 Apr 2001 18:24:00 -0000 Message-id: <5mbsqda24e.fsf@jtc.redback.com> References: X-SW-Source: 2001-04/msg00027.html >>>>> "Frank" == Frank Ch Eigler 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