This is the mail archive of the gdb-patches@sourceware.org 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] | |
> > DSF only updates varObj that are visible on screen. So currently, it always > > uses -var-update with a single varObj name (never use *). > > Which must mean that there is a round trip to the target for each variable > object that needs to be updated. > > This is sounds similar to the previous discussion about using > "-var-list-children --all-values". There Daniel stated that "for a lot of > embedded targets [...] reading memory becomes the dominant time delay". > > Can someone give some typical numbers for "round trip time" vs "reading memory" > time. In my naive understanding of embedded targets, I would have thought the > "round trip time" might be large due to a slow serial link, while "reading > memory" wouldn't change much as all RAM is pretty much the same. Or is the > latter slow because of the time taken to transfer any unneeded extra data back > to the host? I'm not familiar with such numbers myself, although I would be interested in finding out. However, I wanted to point out that there are currently two possible options for var-update -var-update <singleVarObj> -var-update * (we'll ignore the new -var-update @, which does not affect the discussion) For DSF, which tries to minimize the amount of work done, we can: 1- use multiple var-update <singleVarObj>, which typically results in about 5 or 6 var-updates being sent (only 5 or 6 variables are visible on-screen). Then GDB on the target reads the memory for those 5 or 6 varObjs. 2- use var-update *, which results in a single -var-update, but which makes GDB on the target read the memory of all varObjects, which can be anywhere from, say, 5 to 5000, or even more. As you can see, option 2 does not scale, irrespective of which is the true bottleneck, the round-trip time, or the target memory access. That is why DSF does not use var-update *. But you are right that less round-trips would be even better. So, to improve option 1, Vladimir's suggestion of a batch -var-update -var-update <var1> <var2> ... would be better (although DSF is not currently setup for it.) BTW, is there a limit (enforced or recommended) on the number of varObj that can be created? BR, Marc
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |