Re: Always cache memory and registers

[Andrew Cagney <ac131313 at redhat dot com>]

> 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....

Well, given that the target interface is up for an overhaul anyway, this 
fudging is, er, in the hoise.  supply_register(), for instance, needs to 
get parameterized with something meaningful.

In terms of the remote protocol, nothing saying that a T packet can't 
return memory, or that a register/memory fetch can't respond with extra 
info.

For the target vector, my guess is something like:

	target->fetch{register,memory} (<what>, supply-methods)

so that a target can supply anything for a given memory/register request.

Andrew