From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: gdb-ui bogosity with conditional breakpoints Date: Fri, 7 Apr 2006 10:50:13 +1200 Message-ID: <17461.39717.778822.915855@farnswood.snap.net.nz> References: <87k6a3tvnd.fsf@catnip.gol.com> 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 1144363895 32572 80.91.229.2 (6 Apr 2006 22:51:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Apr 2006 22:51:35 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 07 00:51:29 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FRdJp-00007N-Rg for ged-emacs-devel@m.gmane.org; Fri, 07 Apr 2006 00:51:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FRdJp-00077I-IB for ged-emacs-devel@m.gmane.org; Thu, 06 Apr 2006 18:51:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FRdJM-0006yw-TK for emacs-devel@gnu.org; Thu, 06 Apr 2006 18:50:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FRdJL-0006yW-JC for emacs-devel@gnu.org; Thu, 06 Apr 2006 18:50:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FRdJL-0006yR-Ex for emacs-devel@gnu.org; Thu, 06 Apr 2006 18:50:43 -0400 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FRdN6-0003dq-2l; Thu, 06 Apr 2006 18:54:36 -0400 Original-Received: from farnswood.snap.net.nz (p202-124-114-137.snap.net.nz [202.124.114.137]) by viper.snap.net.nz (Postfix) with ESMTP id E6940751B58; Fri, 7 Apr 2006 10:50:31 +1200 (NZST) Original-Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 4D11662A9A; Thu, 6 Apr 2006 23:50:14 +0100 (BST) Original-To: Miles Bader In-Reply-To: <87k6a3tvnd.fsf@catnip.gol.com> X-Mailer: VM 6.97 under Emacs 21.2.1 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 Xref: news.gmane.org gmane.emacs.devel:52483 Archived-At: > I'm running a program invoked with Emacs gdb-ui with a conditional > breakpoint. Normally gdb will appear to just run silently until it hits > the breakpoint and the condition evaluates to true (it's somewhat > slower than normal because of gdb's involvement, but in many cases, > quite usable). > > However, using gdb-ui, it appears to be notifying Emacs _every time_ it > hits the breakpoint, even when the condition is not true! As a result > it's running, but the "run status" in the mode-line keeps flickering > between "[running]" and "[stopped]", and the "current location" icon in > the fring is flashing (at the breakpoint position). You don't say what your condition was, but my crystal ball (which can't see as clearly as Stefan's) says that it calls a function e.g int mysquare (int x) { return x*x; } (gdb) break 81 if mysquare (i) == 49 and that something like (gdb) break 81 if i == 7 doesn't have the same problem. > This _drastically_ slows down execution, far more than the normal speed > penalty for using a conditional breakpoint. It also insists on popping > up the source window every time it hits the breakpoint (even though it > doesn't actually stop), which obviously messes up the user's window > arrangement (continually!). It might be a bit quicker if you use GDB 6.4 as this version doesn't spew out so many annotations for level 3. > Is there anyway to disable this behavior? If so, I think it should be > the default -- the icon and mode-line flashing is not particularly > useful, and the annoyance level is fairly high. If my diagnosis is correct then I think the answer is no, without delving into GDB to stop the erroneous starting and stopped annotations from being generated. I don't plan to do that because a) annotations are being deprecated and b) while setting a condition on a breakpoint with a function is perfectly reasonable, it's probably not done that often. If my diagnosis is wrong, please post a complete testcase and/or the value of gdb-debug-ring (after setting gdb-enable-debug to t at the start of the session). Keep the number of iterations small but if there is still a lot of data please send it off list. -- Nick http://www.inet.net.nz/~nickrob