From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23312 invoked by alias); 15 Jan 2008 20:43:32 -0000 Received: (qmail 23302 invoked by uid 22791); 15 Jan 2008 20:43:31 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 15 Jan 2008 20:43:11 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JEsci-0000De-Dp for gdb-patches@sources.redhat.com; Tue, 15 Jan 2008 20:43:04 +0000 Received: from uslec-66-255-52-67.cust.uslec.net ([66.255.52.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jan 2008 20:43:04 +0000 Received: from ghost by uslec-66-255-52-67.cust.uslec.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jan 2008 20:43:04 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: MI/CLI breakpoint handling code duplication Date: Tue, 15 Jan 2008 20:43:00 -0000 Message-ID: References: <18311.59371.644989.985603@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00363.txt.bz2 Nick Roberts wrote: > [2nd attempt] > > (Fri, 14 Dec 2007 10:26:49 +0400) > >> > * breakpoint.c (break_command_really): New, copied >> > from break_command_1. New parameters COND_STRING, THREAD >> > PARSE_CONDITITION_AND_THREAD and PENDING_BREAK_SUPPORT. >> > The previous FLAG parameter split into TEMPFLAG and >> > HARDWAREFLAG. >> > When PARSE_CONDITION_AND_THREAD is not set, duplicate >> > the passed condition string. >> > (struct captured_breakpoint_args): Remove >> > (do_captured_breakpoint): Remove. >> > (break_command_1): Relay to break_command_really. >> > (gdb_breakpoint): Relay to break_command_really. > >> Ping? This patch is pure refactoring which is basis for >> the 'pending breakpoint in MI' patch. Given that the patch >> is not supposed to change any behaviour and causes no regression, >> I'd hope it should be easy to review :-) > > Previously: > > (gdb) > -break-insert sqrt > &"Function \"sqrt\" not defined.\n" > ^error,msg="Function \"sqrt\" not defined." > (gdb) > > > After this change: > > (gdb) > -break-insert sqrt > &"Function \"sqrt\" not defined.\n" > ^error,msg="unknown error" > (gdb) > > > So this is *not* pure refactoring and happens because gdb_breakpoint used > catch_exceptions_with_msg previously while it now uses catch_exception > through break_command_really. This means now that in mi_cmd_break_insert > > > rc = gdb_breakpoint (address, condition, > 0 /*hardwareflag */ , temp_p, > thread, ignore_count, > pending, > &mi_error_message); > > mi_error_message points to NULL. > > > Furthermore with a sequence like: > > (gdb) > -break-insert main > ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x080485bc",func="main",file="/home/nickrob/myprog.c",fullname="/home/nickrob/myprog.c",line="79",times="0"} > (gdb) > -break-insert sqrt > &"Function \"sqrt\" not defined.\n" > ^error,msg="unknown error" > (gdb) > -exec-run > ^running > (gdb) > *stopped,bkpt={number="-1",type="longjmp > resume",disp="keep",enabled="n",addr="0x00000000",at="",times="0"},bkpt={number="-2",type="longjmp > resume",disp="keep",enabled="n",addr="0x00000000",at="",times="0"},bkpt={number="-4",type="longjmp > resume",disp="keep",enabled="n",addr="0x00000000",at="",times="0"},bkpt={number="-5",type="longjmp > resume",disp="keep",enabled="n",addr="0x00000000",at="",times="0"},reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x080485bc",func="main",args=[{name="argc",value="-1074490904"},{name="argv",value="0xbff49214"}],file="/home/nickrob/myprog.c",fullname="/home/nickrob/myprog.c",line="79"} > (gdb) > > > GDB prints extra output because previous content has not been flushed from > the > stream. I think this is because gdb_breakpoint tries to return int > (really enum REASON, -2 or -1) through break_command_really while it is > type enum gdb_rc (0, 1 or 2). > > So that when gdb_breakpoint fails (and returns RETURN_ERROR = -1) > mi_cmd_break_insert thinks it has suceeded and returns MI_CMD_DONE > (GDB_RC_FAIL = 0): > > if (rc == GDB_RC_FAIL) > return MI_CMD_ERROR; > else > return MI_CMD_DONE; > > I still don't understand the difference between breakpoint handling in MI > and CLI but it must surely have been done differently for a reason. I don't understand the last sentence, but I'll look into fixing the issues you've reported. - Volodya