From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.help Subject: Re: gud : Phase error in gdb-pre-prompt (got pre-emacs) Date: Sat, 28 Jun 2008 11:49:53 +1200 Message-ID: <18533.31905.273260.594090@kahikatea.snap.net.nz> References: <4864aa47$0$7552$9b4e6d93@newsspool1.arcor-online.net> <4864f7c5$0$6607$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1214610639 6815 80.91.229.12 (27 Jun 2008 23:50:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2008 23:50:39 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Markus Grunwald Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jun 28 01:51:23 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KCNis-00011K-Vc for geh-help-gnu-emacs@m.gmane.org; Sat, 28 Jun 2008 01:51:23 +0200 Original-Received: from localhost ([127.0.0.1]:60304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCNi3-0002Cg-6c for geh-help-gnu-emacs@m.gmane.org; Fri, 27 Jun 2008 19:50:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KCNhj-0002Cb-AZ for help-gnu-emacs@gnu.org; Fri, 27 Jun 2008 19:50:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KCNhh-0002CP-T0 for help-gnu-emacs@gnu.org; Fri, 27 Jun 2008 19:50:10 -0400 Original-Received: from [199.232.76.173] (port=49346 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCNhh-0002CM-Mh for help-gnu-emacs@gnu.org; Fri, 27 Jun 2008 19:50:09 -0400 Original-Received: from viper.snap.net.nz ([202.37.101.25]:57501) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KCNhg-0007OH-Ok for help-gnu-emacs@gnu.org; Fri, 27 Jun 2008 19:50:09 -0400 Original-Received: from kahikatea.snap.net.nz (155.62.255.123.dynamic.snap.net.nz [123.255.62.155]) by viper.snap.net.nz (Postfix) with ESMTP id 45BDC3DA944; Sat, 28 Jun 2008 11:50:06 +1200 (NZST) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 20B598FC6D; Sat, 28 Jun 2008 11:49:54 +1200 (NZST) Original-Newsgroups: gnu.emacs.help In-Reply-To: <4864f7c5$0$6607$9b4e6d93@newsspool2.arcor-online.net> X-Mailer: VM 7.19 under Emacs 22.2.50.3 X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:55115 Archived-At: > I tried again with "gdb --annotate=3" (= without binary as parameter) and > loaded the binary with > (gdb) file binary.bin > There was no "initialising..." message visible and I could start > immediately. What's the difference ? Emacs just builds a list of filenames from GDB that were used to build the executable. If you specify the name later in the GUD buffer, it doesn't build that list. That makes it quicker but if there are relevant files in existing buffers or you visit them they won't be enabled for debugging, e.g., you won't be able to click in the fringe to set a breakpoint until execution has already stopped there. > > There are several factors that might make this slow: > > > > 1) An executable that was created from a large number of files. > > gru@PT-AGCMLX1 >find . \( -name \*.cpp -o -name \*.h \) | wc -l > 3072 > > Would this qualify as "large" ? ;) A similar command for Emacs gives 375, so, ..err yes, that does sound rather large. > > 2) Using stabs debug format. > > Hmm, not sure. I just compiled with gcc-2.95 (yes, that old....) and "-g". > "info gcc" gives me the impression that this means stabs or gdb ... In GDB, once execution has started, e.g., after hitting a breakpoint, do (gdb) info source Current source file is myprog.c Compilation directory is /home/nickrob Located in /home/nickrob/myprog.c Contains 262 lines. Source language is c. Compiled with DWARF 2 debugging format. ^^^^^^^ Includes preprocessor macro info. Stabs is an old debug format and I suspect it might be the default for gcc-2.95. Maybe you can compile with DWARF 2 instead (using `-gdwarf-2') then Emacs should start up more qickly. > > 3) Using an old PC. > > gru@CMDevLin2 >cat /proc/cpuinfo > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Pentium(R) 4 CPU 2.40GHz > cpu MHz : 2405.535 > cache size : 512 KB > > Not that old... > CPU is at 20% while "initialising....". > /home is mounted via nfs but I can hardly see any network activity while > "initialising..." By old, I guess I mean 100MHz. It looks like it might not be CPU bound, anyway. > > If this is the problem I can post a patch that might speed things up but > I would try this :) > > > just turning off gud-tooltip-mode might help. > > "gud-tooltip-mode is a variable defined in `gud.el'. > Its value is nil" > > So it is turned off. > > Many thanks for your help :) For the time beeing, I'll just load the > binary from within gdb. Everything seems to work and I don't have to wait > 1:30 minutes. If my colleages see this, I will have to hear their laughter > till the end of days ;) I think that has the same effect as my patch would, i.e., just not build the list. It just means that initially you need to set breakpoints, etc, from the GUD buffer All these tasks that Emacs performs behind the users back should be benchmarked and optimised really, but I just haven't found the time. -- Nick http://www.inet.net.nz/~nickrob