Memory attributes triumphs over dcache

Memory attributes triumphs over dcache

[Frank Ch. Eigler]

Hi -

With the memory attribute system's arrival, the independent
remotecache (dcache) engine has apparently been shut down, as the
memory attribute system doesn't provide a usable alternative.

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

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

(Targets could also endavour to identify control register spaces or
fine-tune the generic memory regions.)


- FChE

Re: Memory attributes triumphs over dcache

[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

Re: Memory attributes triumphs over dcache

[Frank Ch. Eigler]

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
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6y1E2VZbdDOm/ZT0RAoecAJ9/FYWxORgmYYTv9tSCKyWW3T1MAwCeK22y
DJFLWUk+kf7U1bWrvt89yYk=
=bF0u
-----END PGP SIGNATURE-----

Re: Memory attributes triumphs over dcache

[J.T. Conklin]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:
Frank> : [...]
Frank> : I think you may be misunderstanding the code.  [...]

Frank> Yeah, possibly.  I don't actually see any target looking at the
Frank> MEM_WIDTH_* fields!  

Correct for the time being.  I want to fix this as soon as I can with
the remote protocol.  I want to get it right, so not to introduce any
more cruft.  It should be easy to support the width attribute for ROM
monitors that use the infrastructure in monitor.c.  It should also be
easy to add it to the SDS back end, since SDS' SingleStep debugger has
a similar feature.  I don't have a description of the protocol, or I'd
do it myself.  Perhaps no one does, remote-sds.c looks like it was
reverse engineered.

Frank> (BTW, mem_command fails to initialize the new mem_attrib struct
Frank> rigorously.  It should assign defaults to all the optional
Frank> flags explicitly.)

Eh?  Line 142 of memattr.c is "attrib = default_mem_attrib".

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

Since enabling caching should not effect accesses that don't cross
(dcache) line boundaries, this sounds like a bug.  

Perhaps dcache_write_line is breaking things up into byte sized chunks
when it shouldn't be.  I don't use download, so this might be a little
difficult to reproduce.  I appreciate any assistance you might be able
to offer.

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

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

Agreed.  

I've been given patches so that the cache line size and the number of
cache lines can be specified by the user.  It's a trade off.  A large
cache line might be good for downloads, not so good for interactive
use.

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

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

In general, you are correct.  I forgot about that because on the
targets I use breakpoints are inserted and removed by higher level
commands rather than memory reads and writes.

Frank> : but not .data, since I/O devices might
Frank> : DMA into the data region while the target is stopped.
Frank>
Frank> I suppose so, if this is really that frequent or likely an occurrence.
Frank> If it is infrequent, then making the default the opposite makes sense.

Perhaps it is infrequent.  But i've done it from time to time.  More
often the memory is in the heap, not in .data.

What's more likely are cases when the user is attached to one thread,
while other threads are still executing.  My users do this all the
time.

In general, my philosophy is that GDB should do what's always safe by
default, and provide knobs so users can tweak the default behavior when
they know they can get away with it.

-- 
J.T. Conklin
RedBack Networks

Re: Memory attributes triumphs over dcache

[Stan Shebs]

"J.T. Conklin" wrote:
> 
> [...]  It should be easy to support the width attribute for ROM
> monitors that use the infrastructure in monitor.c.  It should also be
> easy to add it to the SDS back end, since SDS' SingleStep debugger has
> a similar feature.  I don't have a description of the protocol, or I'd
> do it myself.  Perhaps no one does, remote-sds.c looks like it was
> reverse engineered.

Not exactly - the source code for their ROM is public, but there
weren't many comments, and some of it I had to figure out by hacking
the ROM sources into a native Unix program, believe it or not, and
connecting to it from GDB while running both the GDB and simulated ROM
under GDBs.  I didn't do the width stuff because the whole thing was
in a bit of a hurry; we didn't get the boards until just a few weeks
before we had to demo GDB working with them (at ESC 1997).

Stan

Re: Memory attributes triumphs over dcache

[J.T. Conklin]

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

Thanks for pointing this out.  dcache_write_line() was totally broken.
Can you try this out?  It works fine for me, but I'm only doing small
writes.  A download might be a better test.

        --jtc

Index: dcache.c
===================================================================
RCS file: /cvs/src/src/gdb/dcache.c,v
retrieving revision 1.14
diff -c -r1.14 dcache.c
*** dcache.c	2001/03/06 08:21:06	1.14
--- dcache.c	2001/04/04 22:32:57
***************
*** 278,297 ****
        while (reg_len > 0)
  	{
  	  s = XFORM(memaddr);
! 	  do {
  	    if (db->state[s] == ENTRY_DIRTY)
  	      break;
  	    s++;
  	    reg_len--;
- 	  } while (reg_len > 0);
  
  	  e = s;
! 	  do {
  	    if (db->state[e] != ENTRY_DIRTY)
  	      break;
  	    e++;
  	    reg_len--;
! 	  } while (reg_len > 0);
  
  	  dirty_len = e - s;
  	  while (dirty_len > 0)
--- 278,301 ----
        while (reg_len > 0)
  	{
  	  s = XFORM(memaddr);
! 	  while (reg_len > 0) {
  	    if (db->state[s] == ENTRY_DIRTY)
  	      break;
  	    s++;
  	    reg_len--;
  
+ 	    memaddr++;
+ 	    myaddr++;
+ 	    len--;
+ 	  }
+ 
  	  e = s;
! 	  while (reg_len > 0) {
  	    if (db->state[e] != ENTRY_DIRTY)
  	      break;
  	    e++;
  	    reg_len--;
! 	  }
  
  	  dirty_len = e - s;
  	  while (dirty_len > 0)
***************
*** 304,309 ****
--- 308,314 ----
  	      memset (&db->state[XFORM(memaddr)], ENTRY_OK, res);
  	      memaddr   += res;
  	      myaddr    += res;
+ 	      len       -= res;
  	      dirty_len -= res;
  	    }
  	}



-- 
J.T. Conklin
RedBack Networks