This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: -var-update @
- From: Michael Snyder <msnyder at specifix dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Nick Roberts <nickrob at snap dot net dot nz>, Marc Khouzam <marc dot khouzam at ericsson dot com>, Vladimir Prus <vladimir at codesourcery dot com>, gdb-patches at sources dot redhat dot com
- Date: Thu, 03 Apr 2008 12:09:52 -0700
- Subject: Re: -var-update @
- References: <200803271338.24328.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04290FD3@ecamlmw720.eamcs.ericsson.se> <18412.2657.401216.698985@kahikatea.snap.net.nz> <20080403185832.GB9403@caradoc.them.org>
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!