From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: Re: GDB startup Date: Wed, 16 Feb 2005 15:44:59 +1300 Message-ID: <16914.45995.842708.102420@farnswood.snap.net.nz> References: <16914.27405.844755.48839@farnswood.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1108523445 24190 80.91.229.2 (16 Feb 2005 03:10:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 Feb 2005 03:10:45 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 16 04:10:44 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D1FaD-0006Ea-VW for ged-emacs-devel@m.gmane.org; Wed, 16 Feb 2005 04:10:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D1Fq5-0004Wb-A2 for ged-emacs-devel@m.gmane.org; Tue, 15 Feb 2005 22:26:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D1FnZ-0003ZZ-OP for emacs-devel@gnu.org; Tue, 15 Feb 2005 22:24:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D1FnU-0003XE-2p for emacs-devel@gnu.org; Tue, 15 Feb 2005 22:24:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D1FnQ-0003Od-J0 for emacs-devel@gnu.org; Tue, 15 Feb 2005 22:24:12 -0500 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D1FD5-0000SD-TL for emacs-devel@gnu.org; Tue, 15 Feb 2005 21:46:40 -0500 Original-Received: from farnswood.snap.net.nz (p147-tnt2.snap.net.nz [202.124.108.147]) by viper.snap.net.nz (Postfix) with ESMTP id 1327B36ED45; Wed, 16 Feb 2005 15:46:38 +1300 (NZDT) Original-Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 679BB62FBE; Wed, 16 Feb 2005 02:45:00 +0000 (GMT) Original-To: Stefan Monnier In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33522 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33522 > Maybe another approach is to limit the buffers that are considered to some > set of major modes, or to some subtree of the filesystem. But neither seems > quite practical. > > Another alternative could be to handle the files/buffers "slowly", with > a 0.5s delay between each file/buffer, starting with the buffers that are > currently visible. I'm not sure that I like either of these very much but here are other alternatives. Currently gdb-ui.el uses the GDB command "info source" to find out if a file is part of the source code of the debug session. There is another command, "info sources", that lists all the files that are part of the source code. Unfortunately only recent versions of GDB give the full pathname for these files, and as it is CLI output the exact syntax might not always be consistent. However, there is also an MI command, -file-list-exec-source-files, that provides this information in a way that can be parsed more simply. This command was added in GDB 6.2, I think. I have also modified MI commands so that, in Emacs, the locals buffer and watch expressions in the speedbar display better information more quickly. These changes were added in version 6.1. GDB get released about two times a year and the current version is 6.3. There is a choice to be made before the next release of Emacs: 1) We can use these new features to improve the behaviour/performance of Emacs with GDB and accept that it won't work with older versions of GDB. or 2) We can accept the current behaviour/performance so that it works with older versions of GDB. As time goes by, 1) becomes more attractive but because there has been no timeline for its release since the "feature freeze" ten months ago (it might be next week or it might be next year) I have conservatively followed 2). Nick