From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32019 invoked by alias); 1 Jun 2006 20:53:43 -0000 Received: (qmail 32007 invoked by uid 22791); 1 Jun 2006 20:53:42 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 Jun 2006 20:53:40 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-246-167.inter.net.il [84.228.246.167]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id DNZ19248 (AUTH halo1); Thu, 1 Jun 2006 23:53:36 +0300 (IDT) Date: Thu, 01 Jun 2006 20:53:00 -0000 Message-Id: From: Eli Zaretskii To: Nathan Sidwell , gdb-patches@sourceware.org In-reply-to: <20060601180321.GA26791@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 1 Jun 2006 14:03:21 -0400) Subject: Re: patch for invalid hw breakpoints Reply-to: Eli Zaretskii References: <447EE9A8.4050800@codesourcery.com> <20060601172639.GA25709@nevyn.them.org> <447F27BC.6030808@codesourcery.com> <20060601180321.GA26791@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00008.txt.bz2 > Date: Thu, 1 Jun 2006 14:03:21 -0400 > From: Daniel Jacobowitz > Cc: Eli Zaretskii , gdb-patches@sourceware.org > > -> Z2,11110000 > <- [empty: I don't support that.] > tries to send: -> z2,11110000 > [internal error, I already know I don't support that!] > > That could be changed in remote.c, but not removing what we didn't > insert does seem cleaner. Is it really clean for remote.c to throw an internal error? I always thought remote.c implemented an API similar to ptrace, so it should behave like ptrace, i.e. return an error code, not throw exceptions. More to the point, I don't like the solution: IMHO it assumes too much about the procedure we use to insert high-level watchpoints. The assumption that we never insert target-side watchpoints past some point in the value chain is not guaranteed to hold forever. If solving this in remote.c seems unclean for some reason (I don't think so, but that's me), how about adding to the watchpoint data structure a flag for each low-level watchpoint we insert, and storing there whether it was actually inserted? The code that removes watchpoints could then consult that flag and refrain from removing a non-inserted watch. Does this make sense?