From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-38831-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 29810 invoked by alias); 11 Mar 2011 07:58:18 -0000
Received: (qmail 29801 invoked by uid 22791); 11 Mar 2011 07:58:17 -0000
X-SWARE-Spam-Status: No, hits=-0.4 required=5.0	tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE
X-Spam-Check-By: sourceware.org
Received: from mailrelay002.isp.belgacom.be (HELO mailrelay002.isp.belgacom.be) (195.238.6.175)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Mar 2011 07:58:10 +0000
X-Belgacom-Dynamic: yes
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAF9keU1tgHE9/2dsb2JhbACKCZwreIhBuFINhVUE
Received: from 61.113-128-109.adsl-dyn.isp.belgacom.be (HELO soleil) ([109.128.113.61])  by relay.skynet.be with SMTP; 11 Mar 2011 08:58:06 +0100
Message-ID: <1EA6FE6B4A03417898402C2C707CADAB@soleil>
From: "Philippe Waroquiers" <philippe.waroquiers@skynet.be>
To: "Tom Tromey" <tromey@redhat.com>
Cc: "Jan Kratochvil" <jan.kratochvil@redhat.com>,	"robert song" <robertsong.japan@gmail.com>,	<gdb@sourceware.org>,	"Julian Seward" <jseward@acm.org>
References: <AANLkTimsE5nNEZ=EKo1wPs0BW9dNxdvVyu_5Fucts5K8@mail.gmail.com>	<20110310081154.GA13603@host1.jankratochvil.net>	<AANLkTi=5n0EebJQkWvXvCHnVxy5fEqrxSztdDhhcpCNR@mail.gmail.com>	<20110310103409.GA29242@host1.jankratochvil.net>	<AANLkTi=SB2twFS4bLURaffoaO25-N7OFwB+nz7w7mjyZ@mail.gmail.com>	<20110310134453.GA11068@host1.jankratochvil.net>	<FD8E0CA1171A4A4AAD80B5E5C0747567@soleil> <m3bp1iadtt.fsf@fleche.redhat.com>
Subject: Re: Why no hwatch command in gdb ?
Date: Fri, 11 Mar 2011 07:58:00 -0000
MIME-Version: 1.0
Content-Type: text/plain;	format=flowed;	charset="iso-8859-1";	reply-type=original
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2011-03/txt/msg00085.txt.bz2

> Why can't this be negotiated between gdb and the remote?
> Then the in-valgrind gdbserver could just report unlimited and the user
> wouldn't have to fool around.
This is for sure the best approach. This would be a new approach,
that would be a general solution, matching various hardware (and
not only the "Valgrind hardware"). I suppose the same approach
should be done for "non remote" hardware watchpoints.

What I have added to gdb follows the current logic, i.e. mostly
"assume the best, and if it fails, tell the user so that limits can be
reduced and/or can decide to switch to software breakpoints".
I will prepare a patch with what I have done.

Philippe