Re: Always cache memory and registers

[Andrew Cagney <ac131313@redhat.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