From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "hui wang" Newsgroups: gmane.emacs.help Subject: Re: gud : Phase error in gdb-pre-prompt (got pre-emacs) Date: Thu, 3 Jul 2008 15:16:39 +0800 Message-ID: References: <4864aa47$0$7552$9b4e6d93@newsspool1.arcor-online.net> <4864f7c5$0$6607$9b4e6d93@newsspool2.arcor-online.net> <18533.31905.273260.594090@kahikatea.snap.net.nz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3982_5094355.1215069399502" X-Trace: ger.gmane.org 1215069440 9256 80.91.229.12 (3 Jul 2008 07:17:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Jul 2008 07:17:20 +0000 (UTC) Cc: Markus Grunwald , help-gnu-emacs@gnu.org To: "Nick Roberts" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jul 03 09:18:03 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 1KEJ4r-00085a-KL for geh-help-gnu-emacs@m.gmane.org; Thu, 03 Jul 2008 09:18:02 +0200 Original-Received: from localhost ([127.0.0.1]:38948 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KEJ40-0004fg-Nn for geh-help-gnu-emacs@m.gmane.org; Thu, 03 Jul 2008 03:17:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KEJ3f-0004fT-99 for help-gnu-emacs@gnu.org; Thu, 03 Jul 2008 03:16:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KEJ3d-0004eT-Jm for help-gnu-emacs@gnu.org; Thu, 03 Jul 2008 03:16:46 -0400 Original-Received: from [199.232.76.173] (port=36070 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KEJ3d-0004eQ-GL for help-gnu-emacs@gnu.org; Thu, 03 Jul 2008 03:16:45 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:59536) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KEJ3c-0002iM-GU for help-gnu-emacs@gnu.org; Thu, 03 Jul 2008 03:16:45 -0400 Original-Received: from fk-out-0910.google.com ([209.85.128.184]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KEJ3a-0006WC-9n for help-gnu-emacs@gnu.org; Thu, 03 Jul 2008 03:16:42 -0400 Original-Received: by fk-out-0910.google.com with SMTP id 18so518677fkq.10 for ; Thu, 03 Jul 2008 00:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=o2MqnqwgKCFLcS2jJLpBhksajFuTO2UhKFyHzD59Jo0=; b=YI/HGRloggZHj+e2j+G/xVB4WI9xy77ViTbY71Isknfwr90vCEGfVhHB9c8DsAUP8F u4RYeDrMsu9KqYdOW7sNahyY5dixO2b46yyYLV68xF8FKiv7S6/VXJKigloBjevP1jf0 M8hIJ9wCvChLFRx5G/8Zi6JTyXEzAEyqFLNis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=omwKGjYBPvRBIs48UmB597l8rs4LoaBuhwXR1Fs0ouDeAoOlKLcVmd7b8wDhwNQaHG oQnYxLI5N2sAbTR/UcHbJZeA1iTQGrS5byiTp0Y1m4XtBkWa4K/iHNP+7GJ2uo7f7TSF olDXtrydAJoiVE7d/RuEJpICjh/sNHSG1Cr78= Original-Received: by 10.82.111.8 with SMTP id j8mr250139buc.47.1215069399517; Thu, 03 Jul 2008 00:16:39 -0700 (PDT) Original-Received: by 10.82.123.14 with HTTP; Thu, 3 Jul 2008 00:16:39 -0700 (PDT) In-Reply-To: <18533.31905.273260.594090@kahikatea.snap.net.nz> X-detected-kernel: by mx20.gnu.org: Linux 2.6 (newer, 2) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:55210 Archived-At: ------=_Part_3982_5094355.1215069399502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/6/28 Nick Roberts : > > 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. > How to disable emacs from "builds a list of filenames from GDB?" I have the same problem, and You have given me similiar solution. But it does not work. So now, I prefer emacs not build it. Maybe there should be a flag for it. > > > > 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 > > > ------=_Part_3982_5094355.1215069399502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

2008/6/28 Nick Roberts <nickrob@snap.net.nz>:
 > 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.
How to disable emacs from "builds a list of filenames from GDB?"
I have the same problem, and You have given me similiar solution. But it does not work.
So now, I prefer emacs not build it. Maybe there should be a flag for it.

 > > 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



------=_Part_3982_5094355.1215069399502--