From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126256 invoked by alias); 29 Aug 2018 15:33:46 -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 126228 invoked by uid 89); 29 Aug 2018 15:33:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=fire, HTo:U*tim, Hx-languages-length:1631 X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Aug 2018 15:33:43 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w7TFXbT8011768 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 29 Aug 2018 11:33:41 -0400 Received: by simark.ca (Postfix, from userid 112) id 09E6E1E4A3; Wed, 29 Aug 2018 11:33:37 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id E3F191E05F; Wed, 29 Aug 2018 11:33:35 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 29 Aug 2018 15:33:00 -0000 From: Simon Marchi To: Tim Newsome Cc: gdb Subject: Re: gdb requires watchpoints to fire after the write In-Reply-To: References: Message-ID: <3833782b96d47551263798eb78f448bd@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00048.txt.bz2 On 2018-08-28 18:08, Tim Newsome wrote: > 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. I don't have experience with many different architectures, but as far as I know, the expectation of the GDB is that the watchpoint is reported after the write. Otherwise it wouldn't need to save the value of the watched expression. That's also how software watchpoints seem to work. The easiest way to deal with this would be to match GDB's expectation. But if you really prefer the behavior of reporting the watchpoint before the event, I suppose it's always possible to teach GDB about this, but it's a less trivial task. Especially that when you GDB evaluates whether the watch expression has changed value, it would need to consider the not-yet-written value in memory. I'm also curious to know if other architectures work in this way (report the event before the write actually take place). Simon