Re: Always cache memory and registers

Andrew Cagney
2003-06-23T14:13:40Z

> 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