-var-update @
Michael Snyder
msnyder@specifix.com
Thu Apr 3 20:05:00 GMT 2008
On Thu, 2008-04-03 at 14:58 -0400, Daniel Jacobowitz wrote:
> On Fri, Mar 28, 2008 at 08:58:09AM +1200, Nick Roberts wrote:
> > > 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?
>
> Reading memory from the target is usually, in my experience, dominated
> by round trip time. There's at least three different round trips
> involved: MI frontend to GDB, GDB to debug server, debug server over
> hardware probe to the target. Because GDB and the remote protocol
> are synchronous, only one memory read can happen at a time, so the
> first two always have to wait at least the length of the last one.
> A typical USB probe takes between 3ms and 10ms to read memory; that's
> just how USB works. I've seen reports that on Windows's USB stack
> it's more like 50ms but I haven't confirmed that myself yet.
>
> For typical use this delay is independent of the amount of memory
> you're reading, until it gets very large. Four bytes and four hundred
> take about the same time.
Only if gdb requests it all in one go.
Sometimes it reads it a word at a time...
in that case all those round trips can really add up!
More information about the Gdb-patches
mailing list