This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: more on gdb server
- To: Quality Quorum <qqi at world dot std dot com>
- Subject: Re: more on gdb server
- From: jtc at redback dot com (J.T. Conklin)
- Date: 18 Jul 2001 10:03:23 -0700
- Cc: Andrew Cagney <ac131313 at cygnus dot com>,Stan Shebs <shebs at apple dot com>, gdb at sources dot redhat dot com
- References: <Pine.SGI.4.21.0107181232060.13093-100000@world.std.com>
- Reply-To: jtc at redback dot com
> > I know HP were once playing with ideas that would have eliminated any
> > copying because they were finding memory read/write performance using
> > ptrace (or what ever) lacking.
>
> I would suppose they had something truly unusual - debuggin is going with
> the pace of human reaction to debugging events and I can hardly imagine
> that network performance over local loop interface would be a factor here.
Remember that GDB may be issuing many low level commands for each high
level (CLI) command. For example, a single step or next command may
issue several step instruction, fetch registers, and store registers
commands. On some large programs, some interactive commands are
beyond the interactive threshold (something like .3 seconds? I can't
remember the commonly quoted figure), this additional overhead would
only make it worse.
Also note that oftentimes it's not a human driving the debugging
session, but user defined functions that grovel through data
structures, call inferior functions, etc.
--jtc
--
J.T. Conklin
RedBack Networks