* Memory attributes triumphs over dcache @ 2001-04-03 12:08 Frank Ch. Eigler 2001-04-03 18:24 ` J.T. Conklin 0 siblings, 1 reply; 6+ messages in thread From: Frank Ch. Eigler @ 2001-04-03 12:08 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Memory attributes triumphs over dcache 2001-04-03 12:08 Memory attributes triumphs over dcache Frank Ch. Eigler @ 2001-04-03 18:24 ` J.T. Conklin 2001-04-04 9:52 ` Frank Ch. Eigler 0 siblings, 1 reply; 6+ messages in thread From: J.T. Conklin @ 2001-04-03 18:24 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: gdb >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Memory attributes triumphs over dcache 2001-04-03 18:24 ` J.T. Conklin @ 2001-04-04 9:52 ` Frank Ch. Eigler 2001-04-04 11:01 ` J.T. Conklin 2001-04-04 15:50 ` J.T. Conklin 0 siblings, 2 replies; 6+ messages in thread From: Frank Ch. Eigler @ 2001-04-04 9:52 UTC (permalink / raw) To: J.T. Conklin; +Cc: gdb 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----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Memory attributes triumphs over dcache 2001-04-04 9:52 ` Frank Ch. Eigler @ 2001-04-04 11:01 ` J.T. Conklin 2001-04-04 14:19 ` Stan Shebs 2001-04-04 15:50 ` J.T. Conklin 1 sibling, 1 reply; 6+ messages in thread From: J.T. Conklin @ 2001-04-04 11:01 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: gdb >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Memory attributes triumphs over dcache 2001-04-04 11:01 ` J.T. Conklin @ 2001-04-04 14:19 ` Stan Shebs 0 siblings, 0 replies; 6+ messages in thread From: Stan Shebs @ 2001-04-04 14:19 UTC (permalink / raw) To: jtc; +Cc: Frank Ch. Eigler, gdb "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Memory attributes triumphs over dcache 2001-04-04 9:52 ` Frank Ch. Eigler 2001-04-04 11:01 ` J.T. Conklin @ 2001-04-04 15:50 ` J.T. Conklin 1 sibling, 0 replies; 6+ messages in thread From: J.T. Conklin @ 2001-04-04 15:50 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: gdb >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-04-04 15:50 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-03 12:08 Memory attributes triumphs over dcache Frank Ch. Eigler 2001-04-03 18:24 ` J.T. Conklin 2001-04-04 9:52 ` Frank Ch. Eigler 2001-04-04 11:01 ` J.T. Conklin 2001-04-04 14:19 ` Stan Shebs 2001-04-04 15:50 ` J.T. Conklin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).