From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3546 invoked by alias); 3 Mar 2007 19:24:23 -0000 Received: (qmail 3536 invoked by uid 22791); 3 Mar 2007 19:24:22 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 Mar 2007 19:24:18 +0000 Received: from kahikatea.snap.net.nz (161.61.255.123.dynamic.snap.net.nz [123.255.61.161]) by viper.snap.net.nz (Postfix) with ESMTP id 7420E3D9A13; Sun, 4 Mar 2007 08:24:15 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id B45B24F714; Sun, 4 Mar 2007 08:24:13 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17897.52060.139181.614251@kahikatea.snap.net.nz> Date: Sat, 03 Mar 2007 19:24:00 -0000 To: =?ISO-8859-1?Q?Alp=E1r_J=FCttner?= Cc: Daniel Jacobowitz , gdb@sourceware.org Subject: Re: (Not) debugging STL In-Reply-To: <1172932555.4011.25.camel@mikro.mikro> References: <1172750690.4155.24.camel@mikro.mikro> <20070301121854.GA10896@caradoc.them.org> <1172752794.4155.35.camel@mikro.mikro> <20070301124621.GA11292@caradoc.them.org> <1172864572.4272.21.camel@mikro.mikro> <17897.23824.618849.817120@kahikatea.snap.net.nz> <1172926723.4011.11.camel@mikro.mikro> <1172932555.4011.25.camel@mikro.mikro> X-Mailer: VM 7.19 under Emacs 22.0.94.3 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00044.txt.bz2 > It seems to me that variable 'gud-last-last-frame' contains the name of > current source file. Thus I tried the following. > > (defun my-step () > (interactive) > (gud-step 1) > (while (string-match "/usr/.*" (car gud-last-last-frame)) > (gud-step 1))) > > However this did not work, I think because gud-step doesn't seem to > update the variable gud-last-last-frame. At least the following function > always prints the same string twice. > > (defun m-step () > (interactive) > (print (car gud-last-last-frame)) > (gud-step 1) > (print (car gud-last-last-frame)) > ) It probably doesn't print a different string because the interaction between Emacs and GDB is asynchronous i.e. Emacs Prints gud-last-last-frame Sends "step" to GDB Prints gud-last-last-frame Receives GDB output Updates gud-last-last-frame so gud-last-last-frame is printed for the second time *before* it is updated. > What to do then? Shall I use something else instead of gud-step? If you look at the file that I have written, gdb-ui.el in Emacs 22, you'll see it uses queues to solve this kind of problem i.e waits for the output of one command before sending the next. However I must point out it uses annotations which are an extension to the fullname marker that I referred to earlier, and these are being deprecated in favour of a new interface called GDB/MI. All this is described in the manual. -- Nick http://www.inet.net.nz/~nickrob