From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50200 invoked by alias); 23 Oct 2018 10:34:15 -0000 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 Received: (qmail 50100 invoked by uid 89); 23 Oct 2018 10:34:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=day X-HELO: mail-wm1-f66.google.com Received: from mail-wm1-f66.google.com (HELO mail-wm1-f66.google.com) (209.85.128.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Oct 2018 10:34:12 +0000 Received: by mail-wm1-f66.google.com with SMTP id y144-v6so1206012wmd.4 for ; Tue, 23 Oct 2018 03:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=IRGHy4B+5MmV3a4rtnPxA1CaIy+sITchtrXUoXlKLbM=; b=W1Rhms4kK1t5A1MH3r/dLQ7HAaH6EIlE129KxIvHHeUepZs8mfvOZwQXGBFZ2qY3cu J4lYn/xzGvWxHT0TMa8orsdEJBUpDRKhGr3J3OI6D16dkQL3W6h/4Sh9Rfikgb6g6W8Y OVlvzJp9Jpn0o62/6j3UMw+BF4uuh35bSPifprR4EBsO3t5bw522yYpwiW8cSugeMFO7 TD5i1KTjNfgPvZ8klOfVeX8O2wu9sUWm2ZuEp6om5vhyoHAB3msnmxFD+hEbmdeVp5Oc QuwdbmqG+i/St91NwXmqGUr/N1XhVtBD+B1MoFVYPSFicIogL/WvO9BB8S0pKcn5pCky SfWw== Return-Path: Received: from localhost (host86-164-85-193.range86-164.btcentralplus.com. [86.164.85.193]) by smtp.gmail.com with ESMTPSA id w11-v6sm775428wrn.65.2018.10.23.03.34.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 Oct 2018 03:34:09 -0700 (PDT) Date: Tue, 23 Oct 2018 10:34:00 -0000 From: Andrew Burgess To: Craig Blackmore Cc: Joel Brobecker , Pedro Alves , Paul Koning , gdb-patches@sourceware.org Subject: Re: [PATCH] RISC-V: enable have_nonsteppable_watchpoint by default Message-ID: <20181023103408.GI2929@embecosm.com> References: <20180917103409.GJ5952@embecosm.com> <77978648-c391-0011-6c03-c7fd38429914@embecosm.com> <20181003223703.GA22933@adacore.com> <20181008095839.GC5952@embecosm.com> <4c4c1369-0f5c-549a-ed82-51563c5e6dd6@redhat.com> <20181008142533.GA2993@adacore.com> <5019D845-3AEB-4287-A8BD-D9F96F5755B7@comcast.net> <20181008145132.GB2993@adacore.com> <5bd138ad-4d1d-254c-9d35-1873b2d8f5f4@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5bd138ad-4d1d-254c-9d35-1873b2d8f5f4@embecosm.com> X-Fortune: Happiness adds and multiplies as we divide it with others. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00500.txt.bz2 * Craig Blackmore [2018-10-09 18:20:04 +0100]: > > > On 08/10/18 15:51, Joel Brobecker wrote: > >>> I think MIPS is one. The documentation is not entirely clear but > >>> that's what I remember from using it. > >> x86 is another. But my question is -- do we know of any RISC-V > >> implementation that triggers after the write, given that the spec > >> says it should trigger before the write. > I don't know of any RISC-V implementations that trigger after the write. > The debug spec has 'suggested breakpoint timings' but the triggers are > allowed to fire at whatever point is most convenient for the implementation. > > I suggest that Joel's earlier patch > (https://sourceware.org/ml/gdb-patches/2018-09/msg00821.html) be > upstreamed so that things work for the majority of systems. We can > handle implementations with other timings later, if they appear. I've gone ahead and pushed Joel's patch into master, commit 5a77b1b49f4. Thanks, Andrew > > Thanks, > Craig > > > That was what I meant as well; I agree with Pedro that we don't > > really need to do anything fancy if: > > - the spec's recommendation is to trigger before the write > > - and we don't know of any system that decided to go against > > the recommendation. > > The day we discover a system that does in fact go against the > > recommendation, we can simply deal with it then and decide what > > the best course of action is. > > > >