Always cache memory and registers

[Daniel Jacobowitz]

On Sun, Jun 22, 2003 at 06:54:48PM -0400, Andrew Cagney wrote:
> 
> >>The only proviso being that the the current cache and target vector 
> >>would need to be modified so that the cache only ever requested the data 
> >>needed, leaving it to the target to supply more if available (much like 
> >>registers do today).  The current dcache doesn't do this, it instead 
> >>pads out small reads :-(
> >
> >
> >It needs tweaking for other reasons too.  It should probably have a
> >much higher threshold before it starts throwing out data, for one
> >thing.
> >
> >Padding out small reads isn't such a bad idea.  It generally seems to
> >be the latency that's a real problem, esp. for remote targets.  I think
> >both NetBSD and GNU/Linux do fast bulk reads native now?  I'd almost
> >want to increase the padding.
> 
> No, other way.
> 
> Having GDB pad out small reads can be a disaster - read one too many 
> bytes and ``foomp''.  This is one of the reasons why the dcache was 
> never enabled.

What do you mean?  I would have thought this was the responsibility of
the stub to manage...

> However, it is totally reasonable for the target (not GDB) to supply 
> megabytes of memory mapped data when GDB only asked for a single byte! 
> The key point is that it is the target that makes any padding / transfer 
> decisions, and not core GDB.  If the remote target fetches too much data 
> and `foomp' then, hey not our fault, we didn't tell it to read that 
> address :-^

Oh, I see what you're getting at.  Hmm, this would require fudging the
interfaces a bit, in order for the target to return excess memory.  It
could be done.  Hm....

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer