Re: Always cache memory and registers

Daniel Jacobowitz
2003-06-23T03:57:13Z

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