From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10794 invoked by alias); 17 Feb 2006 19:38:46 -0000 Received: (qmail 10786 invoked by uid 22791); 17 Feb 2006 19:38:46 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 19:38:45 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-152-98.inter.net.il [80.230.152.98]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DOW57883 (AUTH halo1); Fri, 17 Feb 2006 21:38:41 +0200 (IST) Date: Fri, 17 Feb 2006 19:52:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb@sources.redhat.com In-reply-to: (message from Vladimir Prus on Fri, 17 Feb 2006 18:47:59 +0300) Subject: Re: MI: reporting of multiple breakpoints Reply-to: Eli Zaretskii References: <20060217153211.GA21402@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00197.txt.bz2 > From: Vladimir Prus > Date: Fri, 17 Feb 2006 18:47:59 +0300 > > > The CLI does the same thing; so does the core of GDB, unsurprisingly. > > For ordinary breakpoints, yes. For watchpoints, not quite: That's because breakpoint.c treats breakpoints and watchpoints differently in this regard, I don't know why. You will see that print_it_typical returns PRINT_SRC_AND_LOC for breakpoints, but PRINT_UNKNOWN for watchpoints. Does anyone know why we return PRINT_SRC_AND_LOC for breakpoints? > CLI reports two watchpoints, and MI reports just one. Both should report all of them, IMHO. > I did not test more complex combinations, like mix of watchpoints > and breakpoints that trigger on the same line. I don't think you will find anything interesting by mixing those, at least not on x86. Setting a breakpoint replaces the original instruction by a special opcode, so the original instruction cannot run and trigger the watchpoint. After the breakpoint is hit, GDB restores the original instruction, and then the watchpoint triggers. So GDB will always see these two as separate events, each one stopping the inferior in its own due time. Similar things happen if you use hbreak: the x86 architecture causes the hardware breakpoint to break _before_ the instruction runs, but a watchpoint breaks _after_ the instruction runs. So again there are two separate events.