This is the mail archive of the 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]

Re: Performance issue of -var-list-children on structs with many members and remote targets

On 08/08/2014 12:31 PM, Yao Qi wrote:
On 08/08/2014 03:25 PM, Raphael Zulliger wrote:
Now my simple question: Couldn't GDB be tweaked to get the struct member
values by just one call (because members within a struct are guaranteed
to be consecutive, aren't they?):

499,883 38-var-list-children var2.public
499,884 &"Sending packet: $m601050,24#??"

I guess this would dramatically increase overall performance.

I would really like to see such an improvement in GDB. Therefore, I'd be
very happy to hear your thoughts and suggestion. Thinks like: What
problems (e.g. border cases) could arise when implementing this? Where
to start in the GDB code for such a modification? Or do there exist any
GDB switches to improve performance on such operations? etc...
I have no idea how to merge multiple reads into one.
Thanks for your response!

I guess you are aware of the fact that -data-evaluate-expression is already getting the data in the most efficient way, see e.g.:

-data-evaluate-expression --thread 1 --frame 0 g_s
&"Sending packet: $m601050,18#2e..."
&"Packet received: 000000000000f03f00000000000000000000000000000000\n"
^done,value="{a = 1, b = 0, c = 0}"

Couldn't we do the same during a '-var-update' for a struct like varobj and let it propagate the values to it's children, instead of letting the children update their values?

An implementation could probably indeed be done with a cache system, as suggested by you below. Then the "only" changes would be to implement that cache and to update struct-like varobj *before* traversing their children. Would something like that make sense?

Cache is used in GDB to read code and stack from target, which
increases performance to some extent (See target_read_code and
target_read_stack).  However, cache is NOT used to read general data.
Probably, you can make general data reading use cache too.
In our use case, we're debugging real-time systems in which (global) data often changes at a rapid rate and thus the cache alone wouldn't help much.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]