From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19141 invoked by alias); 14 Sep 2007 12:15:11 -0000 Received: (qmail 19132 invoked by uid 22791); 14 Sep 2007 12:15:10 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Sep 2007 12:15:04 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 13400982A2; Fri, 14 Sep 2007 12:15:02 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id E29B49829E; Fri, 14 Sep 2007 12:15:01 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IWA4a-0005HI-FA; Fri, 14 Sep 2007 08:15:00 -0400 Date: Fri, 14 Sep 2007 12:15:00 -0000 From: Daniel Jacobowitz To: Emi SUZUKI Cc: gdb-patches@sourceware.org Subject: Re: [RFC] checking the Z-packet suppport on gdbserver Message-ID: <20070914121500.GA18934@caradoc.them.org> Mail-Followup-To: Emi SUZUKI , gdb-patches@sourceware.org References: <20070913.210822.19763360.emi-suzuki@tjsys.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070913.210822.19763360.emi-suzuki@tjsys.co.jp> User-Agent: Mutt/1.5.15 (2007-04-09) 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: 2007-09/txt/msg00177.txt.bz2 On Thu, Sep 13, 2007 at 09:08:22PM +0900, Emi SUZUKI wrote: > GDB decides which type of watchpoints should be set when giving the > command like "watch foo". And hardware watchpoints can be used when > gdbserver has the Z-packet support. However, as the session log above > has shown, GDB does not check the Z-packet support on gdbserver when > deciding the type of the watchpoint but when actually setting the > watchpoint to the target. This is an interesting problem. There are a couple of parts to it. Watchpoints are stored in a table, along with breakpoints. The table entries last the entire GDB session, unless they are deleted by the user. In that time, the user can disconnect from the remote target and connect to a different one, or to a native process. One of these might support hardware watchpoints; another might not. That's one reason we don't check when the watchpoint is created. But it isn't a very good reason; you can't set hardware watchpoints before "run" either, and no one complains about that. We could solve this by setting just a "watchpoint", and deciding whether it was a "software watchpoint" or "hardware watchpoint" later on. Or we could just not worry about it. Not worrying about it is probably OK. So on to the more relevant part. Native targets define several methods for dealing with watchpoints: int (*to_can_use_hw_breakpoint) (int, int, int); int (*to_remove_watchpoint) (CORE_ADDR, int, int); int (*to_insert_watchpoint) (CORE_ADDR, int, int); int (*to_stopped_by_watchpoint) (void); int to_have_steppable_watchpoint; int to_have_continuable_watchpoint; int (*to_stopped_data_address) (struct target_ops *, CORE_ADDR *); int (*to_region_ok_for_hw_watchpoint) (CORE_ADDR, int); And, inconsistently, the gdbarch method gdbarch_have_nonsteppable_watchpoint. The steppable / nonsteppable / continable distinction describes what happens after a watchpoint is hit; whether it can be single stepped while inserted, must be removed and stepped past, or is already past. This varies by architecture but also by target, e.g. a simulator might implement nonsteppable watchpoints for i386 (which normally has continuable watchpoints). to_region_ok_for_hw_watchpoint decides whether a region is too big or misaligned to be watched. to_can_use_hw_breakpoint decides whether too many hardware watchpoints have been requested. The remote target can't implement either of these. Figuring out the answer to either is a bit complicated. Every architecture's watchpoints work a bit differently. Before I think about how to do it, the question is: should we bother? Or is the any watchpoints / no watchpoints distinction good enough? We can use qSupported to convey any information we like from the target to GDB but once we get the data we have to figure out what to do with it. -- Daniel Jacobowitz CodeSourcery