This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
One thing that could be added to this is the idea of a sync point.
When supplying data, the target could mark it as volatile. Such volatile data would then be drawn from the cache but only up until the next sync point. After that a fetch would trigger a new read. Returning to the command line, for instance, could be a sync point. Individual x/i commands on a volatile region would be separated by sync points, and hence would trigger separate reads.
Thoughts. I think this provides at least one techical reason for enabling the cache.
Interesting idea there. I'm not quite sure how much work vs. return it would be.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |