This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

memory regions, dcache


Setting aside symbol table performance for the moment, I'm back
finishing up memory region attributes.

In previous messages, I've shared my changes to target_xfer_memory().
Those have not changed significantly.  Since that time, I've added a
'mem_attrib *attrib' argument to the target vectors to_xfer_memory()
function, and have fixed up all the code for all the targets.  While I
was there, I noticed that some target's *_xfer_memory() function did
not declare the 'struct target_ops *target' argument, so I fixed that
up at the same time.  (Btw, Are there any *_xfer_memory() functions
that use the 'target' argument?  I didn't see any while I was adding
the new argument, but I wasn't looking for it either.  If nothing uses
it, I wouldn't mind removing it as part of this change.)

Now that the mem_attrib argument is available, target *_xfer_memory()
functions may be able to tailor their behavior accordingly.  I say
'may be able' because currently most of the functions simply ignore
the new arguement (either because the function has not been changed to
use the attribute, or perhaps because the host/target interface/
protocol cannot support the attribute(s) selected.  Is there anything
I should do about this now, or is the fact that some attributes are
not supported on all targets a given that just needs to be documented?

In most of the embedded remote targets, the target vector code calls
dcache_init() in the *_open() function to register functions used to
read and write memory, and the *_xfer_memory() functions calls
dcache_xfer_memory() which uses the functions registered earlier to
perform the I/O.  The problem is that there is no way to pass the
attribute argument through dcache to the functions.  

This should be fairly easy to address --- just a lot of grunt work
fixing up dcache_xfer_memory() and the read and write functions to
take the new argument.  However, I wonder whether it would be better
(cleaner, more "elegant", etc.) to move dcache up a layer and put it
between target_xfer_memory() and the target *_xfer_memory() functions.

For example, instead of calling a target vector's *to_xfer_memory(),
target_xfer_memory() would call dcache_xfer_memory() with a target
vector pointer.  If dcache_xfer_memory() had to do i/o, it would call
the target vector's *to_xfer_memory() function.

Having the dcache at a higher level might be useful for implementing
the verify (read and compare after writes) attribute.  As I imagine
things, verify support would be implemented in target_xfer_memory()
and would re-read and compare after a write.  But if the target code
uses dcache, the read would not come from the target but the cache.
On the other hand, target_xfer_memory() could do a cache invalidate
before reading (and a more refined cache invalidate could easily be
written).

All that being said, I think that going the simple route and adding
the parameter to dcache_xfer_memory() and to the target read/write
functions may be the right thing for now.  It won't be difficult to
re-evaluate this decision and go for the more integrated approch if
that turns out to be the right thing over time.

One more thing before this gets too long.  There is a remotecache
variable that globally enables the cache which is currently disabled.
With attributes, each memory region has a cache/nocache atttribute.
Should the remotecache variable override the attribute.  Or can we
depricate remotecache completely?  Since when no memory attributes
are defined the default attribute is used which disables the cache,
there isn't much need for a global flag any more.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]