From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28010 invoked by alias); 27 Mar 2005 14:10:46 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27948 invoked from network); 27 Mar 2005 14:10:38 -0000 Received: from unknown (HELO lakermmtao04.cox.net) (68.230.240.35) by sourceware.org with SMTP; 27 Mar 2005 14:10:38 -0000 Received: from white ([68.9.64.121]) by lakermmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050327141037.YVGB11124.lakermmtao04.cox.net@white>; Sun, 27 Mar 2005 09:10:37 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DFZOE-0000Oe-00; Sun, 27 Mar 2005 10:09:22 -0500 Date: Sun, 27 Mar 2005 14:10:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: GDB Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050327150922.GB1451@white> Mail-Followup-To: Eli Zaretskii , GDB References: <20050325161239.GA12231@white> <01c53207$Blat.v2.4$3def9b00@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c53207$Blat.v2.4$3def9b00@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00247.txt.bz2 On Sat, Mar 26, 2005 at 03:24:10PM +0200, Eli Zaretskii wrote: > > Date: Fri, 25 Mar 2005 11:12:39 -0500 > > From: Bob Rossi > > > > (gdb) > > -break-watch param > > ^done,wpt={number="2",exp="param"} > > (gdb) > > -exec-continue > > ^running > > (gdb) > > ~"Hardware watchpoint 2 deleted because the program has left the block \n" > > ~"in which its expression is valid.\n" > > *stopped,reason="exited",exit-code="02" > > (gdb) > > > > Is it just a bug that there is no 'watchpoint-scope' returned? > > I think it's a bug, yes: there's one instance in breakpoint.c > (specifically, in the function insert_bp_location) that uses > printf_filtered instead of the ui_* functions to produce the warning > about a watchpoint that went out of scope. I think it should use the > same code that is used by watchpoint_check to produce a similar > warning. Sorry, long email, please scan quickly. Unfortunately, this is going to much harder than I originally thought. In fact, it looks like the whole thing is broken. I think part of the problem is the fact that the way the MI output is generated is hackish. I think it's kind of bad that the MI output is basically concatenated strings from the rest of GDB. For instance, I think it would be much better if there were data structures available, and the breakpoint code set up structures with the information that the MI needed. Then later on, the MI could traverse the structure and print what it wanted to. In that way, all of the information needed could be used to print a message at once. It seems as if the watchpoint-scope has 2 problems that I can find. The first is that the manual says, Setting a watchpoint on a variable local to a function. GDB will stop the program execution twice: first for the variable changing value, then for the watchpoint going out of scope. ... -exec-continue ^running ^done,reason="watchpoint-scope",wpnum="5", frame={func="callee3",args=[{name="strarg", value="0x11940 \"A string argument.\""}], file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="18"} (gdb) In the above example, things work fine. However, if you happen to use -exec-next or -exec-finish, something that by itself produces an exec-async-output command, then instead of having 2 async output commands, you get 1, with the data combined. Two example are below, 1 with -exec-continue, and one with -exec-next (gdb) -exec-continue ^running (gdb) ~"Hardware watchpoint 2 deleted because the program has left the block \n" ~"in which its expression is valid.\n" *stopped,reason="watchpoint-scope",reason="exited",exit-code="02" (gdb) (gdb) -exec-next ^running (gdb) ~"Single stepping until exit from function __libc_start_main, \n" ~"which has no line number information.\n" ~"Hardware watchpoint 2 deleted because the program has left the block \n" ~"in which its expression is valid.\n" *stopped,reason="watchpoint-scope",reason="exited-normally" (gdb) Both of the examples above give 2 reasons for the async command. So, the MI syntax is correct, but the semantics are completely wrong. I think it's currently impossible to return 2 async records in 1 MI output command. This is because in mi-main.c the *stopped is hard coded, as if there could only be 1 async reason per command. There will probably have to be some fundamental changes in order to get this to work. I think the rest of GDB needs to be able to tell MI through the uiout that a new async record is ready to be sent, instead of having the MI hard code it. Thanks, Bob Rossi