From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86412 invoked by alias); 28 Aug 2018 22:08:07 -0000 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 Received: (qmail 86400 invoked by uid 89); 28 Aug 2018 22:08:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=instantly, Hx-languages-length:1484, H*r:sk:gdb@sou, fired X-HELO: mail-oi0-f43.google.com Received: from mail-oi0-f43.google.com (HELO mail-oi0-f43.google.com) (209.85.218.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Aug 2018 22:08:06 +0000 Received: by mail-oi0-f43.google.com with SMTP id c190-v6so5680939oig.6 for ; Tue, 28 Aug 2018 15:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=XWSWWXRrMLbHXb6Hvb3r254uzBnm/9k3i/OH0oKUzFc=; b=Vh2fdUVdRSZCGXtseUc6NrsOphW2EJaCwsmK4SAcsccC8EHseDAZxkNimzwIdiBYTK lL9Mb1o1Id+9gukJJCGTMgdDQdpLhw7fVPz74uVx6/sIijr2vOFGkOR5+OCH38cCao33 8EK3WvPQcoEcBkkHZFZyv9KMQVAKFhjpqfab86/rHYEdeazS0y6+lf7HCAEaYc8q2BpP 1XuVPnOJKMuRY7Iq78tPiWjyC6ImPthiA7Vxxz47c55ylA9gthmRmceE1ZVGLcJLU1hu xQkqtALk5tgKEvkfcKIJSBxcPxlUS3K6v2PlF/0WIvC5CP8Xnq40F5vhQf0Cw90QbPrF uCvA== MIME-Version: 1.0 Received: by 2002:a9d:4d0d:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 15:08:03 -0700 (PDT) From: Tim Newsome Date: Tue, 28 Aug 2018 22:08:00 -0000 Message-ID: Subject: gdb requires watchpoints to fire after the write To: gdb Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00047.txt.bz2 The RISC-V Debug Spec suggests that memory write triggers fire before the access actually takes place. This allows a user to see what the value in memory is before it's overwritten. This does not play nice with gdb's watchpoint expectation, however. When a watchpoint is hit, gdb instantly reads the memory that it fired on, and if it hasn't changed it silently lets execution resume. Since on RISC-V the watchpoint fired before the write actually took place, gdb will always miss the first write because memory won't have changed yet. Does that sound right? How should I fix this? With hardware breakpoint functionality being generally all over the map, I can't imagine this hasn't come up before. Thank you, Tim