RE: why is gdb 5.2 so slow

["Howell, David P" <david.p.howell@intel.com>]

Hi Daniel,
See my comments mixed in below with [DPH].

Thanks,
Dave Howell

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com] 
Sent: Friday, November 01, 2002 10:17 AM
To: Andrew Cagney
Cc: wim delvaux; gdb@sources.redhat.com
Subject: Re: why is gdb 5.2 so slow

On Fri, Nov 01, 2002 at 09:58:03AM -0500, Andrew Cagney wrote:
> 
> GDB, to implement a thread-hop (step a single thread over a
breakpoint) 
> with something like (with a Linux Kernel):
> 
	<< Stuff Deleted >>

> Both.  Things we do wrong:
> - GDB can't handle being told that just one thread is stopped.  If we
> could, then we wouldn't have to stop all threads for shared library
> events; there's a mutex in the system library so we don't even have to
> worry about someone hitting the breakpoint.  We could also use this to
> save time on conditional breakpoints; if we aren't stopping, why stop
> all other threads?
[DPH] Depends on what is being done. If going to a prompt to allow the 
	user to examine the state or running breakpoint commands, we may

	not want other threads doing things to change it. It is an 
	expensive thing to do but I expect that we'd find a lot of other

	issues if this changes. 

> - Removing all breakpoints, that's just wrong, there's a test in
> signals.exp (xfailed :P) which shows why.  We should _only_ be
removing
> any breakpoints at the address we're hopping over.
[DPH] I thought we need this to show a clean program space, i.e. without

	gdb's modifications, i.e. breakpoints. My guess is that the code
is
	general that does this and we'd have to put more logic in to
detect 
	when we are poking in the address space after the breakpoint.
>
> - No memory cache by default.  thread_db spends a LOT of time reading
> from the inferior.
[DPH] From what I've looked at this is the big baddie. Lots of pulling
of 
	thread state using ptrace in 4 byte nibbles (IA32
w/linuxthreads). 
	A 'strace -f -o /tmp/trc gdb myprog' is humbling on this front,
there
	are thousands/millions of these calls for stuff like 'info
threads' 
	and other thread operations.

	Some of this can be eliminated with thread_db caching, lots of
the 
	operations are repeats that could be resolved in a cache if the
state
	of the inferior doesn't change and all threads are stopped.
Also, the
	implementation of libthread_db can be fixed to eliminate some of
it
	by eliminating any unnecessary inferior pokes. 

> - No ptrace READDATA request for most Linux targets to read a large
> chunk.  I keep submitting patches for some other ptrace cleanups that
> will let me add this one to the kernel, and they keep hitting a blank
> wall.  I may start maintaining 2.4 patches publicly and see if people
> use them!
[DPH] Yeah, this would help a lot. Is there a reason that 4 byte ptraces
are
	necessary? Some standard or common convention/practice? I
thought of
      using /proc/<pid>/mem with memcpy, but haven't found the time to
flesh
	it out yet. Anyway, if ptrace directly supports it that would
resolve 
	this.

> - Too many calls to thread_db in the LinuxThreads case.  It's a nice
> generic layer but implemented such that the genericity (? :P) comes
> with a severe cost in performance.  We need most of the layer; I've
> seen the NGPT support patch for GDB, and it's very simple, precisely
> because of this layer.  
[DPH] Thanks, that was mine for NGPT. I had on my list caching and
single
	ptrace operations for large inferior block accesses as the next
best
	improvements to make. Minimizing the info pulled as well would
help,
	we currently pull the complete thread structure where we could
define
	a subset that we care about to pull to cut the load. Decoupling
from
	the real structure has support headaches about it though, when
things 
	change the abbreviated structure would need changes.

> But we could do staggeringly better if we just
> had a guarantee that there was a one-to-one, unchanging LWP<->thread
> correspondence (no userspace scheduling etc.).  Both LinuxThreads and
> the new NPTL library have this property.  Then we don't need to use
> thread_db to access the inferior at all, only to collect new thread
> information.
[DPH] Architectures that do M:N will be around for a while, not sure
that 
	this is the right thing to do. Can we make the LWP layer lighter

	for the cases where it's not used? 

> Want a sample of how much difference this last one makes?  In
> combination with a bit of my first bullet above, that means we don't
> have to stop all threads at a new thread event?  Use gdbserver instead
> of GDB.  Its completely from-scratch threads support does not work
with
> NGPT or any other N:M threading library, but for N:N it is drastically
> faster.  The spot that's still slowest is shared library events,
> because we can't report that just that thread stopped and ask if we
> should stop others (or better, be told by GDB that the breakpoint at
> that address is a don't-stop-all-threads breakpoint).
[DPH] I still would vote for the generality to cover the options
available
	in the Linux community, including M:N. But what is there can be
	improved a bunch.
>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

David Howell
Intel Corporation
Telco Server Development
Server Products Division
Voice: (803) 461-6112  Fax: (803) 461-6292

Intel Corporation
Columbia Design Center, CBA-2
250 Berryhill Road, Suite 100
Columbia, SC 29210

david.p.howell@intel.com