From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19687 invoked by alias); 1 Jun 2006 21:12:19 -0000 Received: (qmail 19532 invoked by uid 22791); 1 Jun 2006 21:12:18 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 01 Jun 2006 21:12:04 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FluSV-0000By-5a; Thu, 01 Jun 2006 17:11:59 -0400 Date: Thu, 01 Jun 2006 21:12:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Nathan Sidwell , gdb-patches@sourceware.org Subject: Re: patch for invalid hw breakpoints Message-ID: <20060601211159.GA557@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Nathan Sidwell , gdb-patches@sourceware.org References: <447EE9A8.4050800@codesourcery.com> <20060601172639.GA25709@nevyn.them.org> <447F27BC.6030808@codesourcery.com> <20060601180321.GA26791@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 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/msg00009.txt.bz2 On Thu, Jun 01, 2006 at 11:53:38PM +0300, Eli Zaretskii wrote: > > 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. Normally it would; this is an internal error, i.e. a failed consistency check. Well, it calls error(), but I think it really qualifies as an internal error. Anyway, do you think it's sensible for a "target_remove_watchpoint" method to be called on something that is not an inserted watchpoint? I'd think no. It could mess up reference counts, for instance. > 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? That seems fine to me. If you recall, long ago I was planning to split this up to have a "low level breakpoint" (struct bp_location) for each value in the chain, and bp_location already has the inserted flag. But I never had time to finish it. This would be a less intrusive way of accomplishing about the same thing. -- Daniel Jacobowitz CodeSourcery