From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16595 invoked by alias); 15 May 2009 15:41:35 -0000 Received: (qmail 16584 invoked by uid 22791); 15 May 2009 15:41:34 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 May 2009 15:41:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DAEC22BABDC; Fri, 15 May 2009 11:41:27 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nxWd6jY3JrXE; Fri, 15 May 2009 11:41:27 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id AC6ED2BAB64; Fri, 15 May 2009 11:41:27 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A095AF5962; Fri, 15 May 2009 17:41:25 +0200 (CEST) Date: Fri, 15 May 2009 15:41:00 -0000 From: Joel Brobecker To: Pierre Muller Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Add hardware breapoints in procfs.c Message-ID: <20090515154125.GO7292@adacore.com> References: <003701c9d4da$6c4f5fb0$44ee1f10$@u-strasbg.fr> <003801c9d4db$380e2ff0$a82a8fd0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003801c9d4db$380e2ff0$a82a8fd0$@u-strasbg.fr> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-05/txt/msg00327.txt.bz2 > 2009-05-14 Pierre Muller > > * procfs.c (procfs_insert_hw_breakpoint, procfs_remove_hw_breakpoint): > New functions. > (procfs_use_watchpoints): Register new hardware breakpoint related > target functions. I don't know procfs enough to review the patch accurately. I think that the part for removing the watchpoint is correct, but I'm wondering about the part that sets the watchpoint. Does it always stop before the instruction gets executed? for instance, if you look at procfs_insert_watchpoint, it does depend on the target: if (!target_have_steppable_watchpoint && !gdbarch_have_nonsteppable_watchpoint (current_gdbarch)) { /* When a hardware watchpoint fires off the PC will be left at the instruction following the one which caused the watchpoint. It will *NOT* be necessary for GDB to step over the watchpoint. */ return procfs_set_watchpoint (inferior_ptid, addr, len, type, 1); } else { /* When a hardware watchpoint fires off the PC will be left at the instruction which caused the watchpoint. It will be necessary for GDB to step over the watchpoint. */ return procfs_set_watchpoint (inferior_ptid, addr, len, type, 0); } Does it matter for h/w breakpoints? -- Joel