From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18185 invoked by alias); 1 Nov 2002 19:43:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18084 invoked from network); 1 Nov 2002 19:43:08 -0000 Received: from unknown (HELO petasus.ch.intel.com) (143.182.124.5) by sources.redhat.com with SMTP; 1 Nov 2002 19:43:08 -0000 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.48 2002/10/16 23:47:34 dmccart Exp $) with SMTP id gA1JiT918241 for ; Fri, 1 Nov 2002 19:44:30 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110111412326201 ; Fri, 01 Nov 2002 11:41:23 -0800 Received: from fmsmsx403.amr.corp.intel.com ([132.233.42.207]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 11:43:06 -0800 content-class: urn:content-classes:message Subject: RE: why is gdb 5.2 so slow Date: Fri, 01 Nov 2002 11:43:00 -0000 Message-ID: <331AD7BED1579543AD146F5A1A44D5251279CE@fmsmsx403.fm.intel.com> MIME-Version: 1.0 X-MS-Has-Attach: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 From: "Howell, David P" To: "Daniel Jacobowitz" , "Andrew Cagney" Cc: "wim delvaux" , X-OriginalArrivalTime: 01 Nov 2002 19:43:06.0871 (UTC) FILETIME=[E6716870:01C281DE] X-SW-Source: 2002-11/txt/msg00012.txt.bz2 Hi Daniel, See my comments mixed in below with [DPH]. Thanks, Dave Howell -----Original Message----- From: Daniel Jacobowitz [mailto:drow@mvista.com]=20 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: >=20 > GDB, to implement a thread-hop (step a single thread over a breakpoint)=20 > with something like (with a Linux Kernel): >=20 << 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=20 user to examine the state or running breakpoint commands, we may not want other threads doing things to change it. It is an=20 expensive thing to do but I expect that we'd find a lot of other issues if this changes.=20 > - 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=20 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=20 thread state using ptrace in 4 byte nibbles (IA32 w/linuxthreads).=20 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'=20 and other thread operations. Some of this can be eliminated with thread_db caching, lots of the=20 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.=20 > - 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//mem with memcpy, but haven't found the time to flesh it out yet. Anyway, if ptrace directly supports it that would resolve=20 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.=20=20 [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=20 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=20 this is the right thing to do. Can we make the LWP layer lighter for the cases where it's not used?=20 > 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. > > --=20 > 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