|Re: [dsdp-dd-dev] FW: RE: -var-update using formatted value|
Daniel Jacobowitz wrote:
On Thu, Jan 17, 2008 at 09:46:16PM -0800, Pawel Piech wrote:Hi Marc, It seems that the question of what and how much to cache in the IDE comes up periodically. In the past, a rule of thumb that we used is that if a given request may go over the network, it's probably worth caching. For GDB, i think using a remote GDB server would involve executing GDB commands over the network, although I honestly can't tell how common is that use case.Using a remote GDB server does not necessarily mean that GDB commands go over the network. GDB runs on the same machine as Eclipse (not always true, but 99% of the time). If GDB can respond to an MI command without going over the network to gdbserver, it will always do so. There's still some benefit to caching in the frontend, because sending commands over a local pipe to GDB/MI still takes time. But it won't be as slow as reading target memory.
I think what Marc meant was that after a resume/suspend, even if -var-update indicates that a given variable hasn't changed the IDE will need to retrieve it's value because of the ambiguity of the value formats. However, only variables which are visible on the screen will be requested by the UI from the service, so if a variable wasn't visible, a -var-update would never be called for it anyway.2- the format-value cache which could simply rely on the internal GDB cache as mentioned in the email below. Since this cache needs a workaround to properly work with the current implementation of var-update, it would be easier to get rid of it. But that means that after every 'Resume', each value, even if not changed will need to be fetched from GDB (but not from GDB-server).Those extra fetches would be unfortunate. Why is this true? You should only need to fetch things that are visible to the user. Once the debugged program has run, GDB needs to ask gdbserver for updated values; that's what -var-update does.
Back to the top