From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1924 invoked by alias); 19 Oct 2010 22:04:34 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 1903 invoked by uid 22791); 19 Oct 2010 22:04:32 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Tue, 19 Oct 2010 22:04:00 -0000 From: Kevin Buettner To: archer@sourceware.org Subject: Re: Q: ugdb && watchpoints Message-ID: <20101019150421.1b0f51df@mesquite.lan> In-Reply-To: <20101019181159.GA10275@redhat.com> References: <20101019181159.GA10275@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2010-q4/txt/msg00020.txt.bz2 On Tue, 19 Oct 2010 20:11:59 +0200 Oleg Nesterov wrote: > I was even thinking about serializing. That is, ugdb schedules only > one thread to step every time. This way at least we can always know > who changes the memory. But this is non-trivial, very bad from > perfomance pov, and doesn't work with syscalls. I think that stepping one thread at a time is the approach that must be taken if you want to accurately report the thread that triggered the watchpoint. (I don't understand the issue with syscalls though...) > Any advice is very much appreciated. Most probably, there is no any > clever solution. Once a traced sub-thread detects that a watchpoint > was changed, it should mark this wp as "reported" for other threads > and report it to gdb. IOW, we report the random thread and random wp. Is there a big performance win in implementing software watchpoints in ugdb? If not, I wouldn't worry about it. My experience with software watchpoints in native gdb is that they're *very* slow and, as such, are often not worth using at all. > Another question. I guess, ugdb should implement hardware watchpoints > as well? Otherwise, there is no any improvement compared to gdbserver > in the likely case (at least I think that a-lot-of-wps is not that > common). But we only have Z2 for both. So I assume that ugdb should > try to use the hardware watchpoints, but silently fall back to > emulating? IMO, hardware watchpoints are definitely worth implementing. From a user perspective, I would prefer that the stub not implement software watchpoint support when the real hardware watchpoints are used up. Hope this helps... Kevin