From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26835 invoked by alias); 7 Jul 2009 15:19:20 -0000 Received: (qmail 26825 invoked by uid 22791); 7 Jul 2009 15:19:19 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp.idnet.com (HELO smtp-out.idnet.com) (212.69.36.238) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Jul 2009 15:19:05 +0000 Received: from localhost (unknown [127.0.0.1]) by smtp-out.idnet.com (Postfix) with ESMTP id B02F52D71F5 for ; Tue, 7 Jul 2009 15:19:02 +0000 (UTC) Received: from smtp-out.idnet.com ([127.0.0.1]) by localhost (smtp-out.idnet.com [127.0.0.1]) (amavisd-new, port 10040) with LMTP id LDRbTam7yyoE for ; Tue, 7 Jul 2009 16:19:01 +0100 (BST) Received: from mail.idnet.net.uk (mail.idnet.net.uk [212.69.36.63]) by smtp-out.idnet.com (Postfix) with ESMTP id 1228B2D736F for ; Tue, 7 Jul 2009 16:19:01 +0100 (BST) Received: from [91.135.5.64] by mail.idnet.net.uk (GMS 15.02.3689/NU3963.00.7ca42f0c) with ESMTP id bmqmjvba for gdb@sourceware.org; Tue, 7 Jul 2009 16:18:56 +0100 Subject: Re: Problem with "watch" on a new port. From: Jeremy Bennett Reply-To: jeremy.bennett@embecosm.com To: Florent Defay Cc: gdb@sourceware.org In-Reply-To: <8502af3c0907070528i1c8cc003lc57006828eb4bde3@mail.gmail.com> References: <8502af3c0907020810k766a9873qc32552180d5fdc64@mail.gmail.com> <1246550027.21485.30.camel@thomas> <8502af3c0907070528i1c8cc003lc57006828eb4bde3@mail.gmail.com> Content-Type: text/plain Date: Tue, 07 Jul 2009 15:19:00 -0000 Message-Id: <1246976796.2548.43.camel@thomas> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthenticatedSender: jeremy.bennett.embecosm.com@idnet.net.uk X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00045.txt.bz2 On Tue, 2009-07-07 at 14:28 +0200, Florent Defay wrote: > Hi, > Thank you very much to all for the answers. > > I am still in trouble with the "watch" issue. > > I give you a concrete example of the problem bellow. > I debug main.c with the target-gdb (remote protocol) in two different ways. Hi Florent, I think some of these issues are down to the OpenRISC 1000 simulator, not GDB. > > My conclusion : > In behavior 1, Hardware watchpoint is used. The problem is > 1- There are no info about old and new value. > 2- The statement a = 3; is not detected. I've looked in the code for the OpenRISC 1000 simulator. Hardware watchpoints are not supported in the RSP interface. They return an empty packet, which *should* cause GDB to realise they are not supported and use software watchpoints. I think this is generic, so it should not require any architecture specific functionality. So I don't understand why this is not working correctly, and reporting a hardware watchpoint being set. It is possible it relies on an aspect of the architecture (in or1k-tdep.c), which has not been implemented. Or it could be a bug in GDB - have you checked Bugzilla? > In behavior 2, Software watchpoint is used. The problem is > 1- It cannot be a final solution because it is very slow. > 2- "Watchpoint 2 deleted because the program has left the block in > which its expression is valid." > is not a good behavior. The call to foo has a secondary unexpected > effect (it is the same behavior every time a function is called). I would expect the first example to behave like this as well. If RSP reports HW watchpoints are not available, a SW watchpoint should be used. I'm not an expert on watchpoints. I don't know why you get the report about the watchpoint being deleted. I would not expect the watchpoint to be deleted until after the program has left it's last loop in main(). However. Is this optimized code? It's quite possible that foo has been inlined. In which case this report may actually be referring correctly to the end of the second loop (which would be the same address in the compiled code). Possibly others on this group can advise more on how software watchpoints are handled. > The simulator (sid) seems to receive Z/z packets well. It may be due > to a mistake in t-dep or something missing but I do not know what. > Plus, step, next, breakpoints, finish work very well. HTH, Jeremy -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: jeremy.bennett@embecosm.com Web: www.embecosm.com