RE: why is gdb 5.2 so slow

Howell, David P
2002-11-01T19:43:09Z

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