From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25788 invoked by alias); 29 Aug 2018 20:13:26 -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 25779 invoked by uid 89); 29 Aug 2018 20:13:26 -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=everybody, H*c:alternative X-HELO: mail-oi0-f51.google.com Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com) (209.85.218.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Aug 2018 20:13:24 +0000 Received: by mail-oi0-f51.google.com with SMTP id t68-v6so11404363oie.12 for ; Wed, 29 Aug 2018 13:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0/Wk6k4EEc2wtvq9jZlm+Nikmyd3xZp1Y4vYF46PYsk=; b=nHlNAt1Q2YAZiw+21plY+epm+lhCfh3+Lj4lfXsLaSXtQDN65+JSRZhUu1A6QIwAd9 Oh1TgrvE5UvjVmGKJpn7teIwOfIMZwsFcjdQxbcw/SMK+/MzjTB8KOiOcGWR13X5eqJ5 PtsqIR+1hctcvSgXNzritXxFOOOiN31aQP0EiFPwsIlNIUT9H3L+Pi+7AwJ3YikcyhSQ RAj6lHQwJRPhUCnLmjudgsmhEmixq1idfE4LlGgI4pLMoqeDzHBFkzK5+71XEXf/q5BT /T/lcjlW0RbPMTP/bRiltdSRDPvVya4TAPfJ1Vs7CL2R2kJy7LPQi5tOwuxxW5b7MV5/ v+Ww== MIME-Version: 1.0 Received: by 2002:a9d:4d0d:0:0:0:0:0 with HTTP; Wed, 29 Aug 2018 13:13:22 -0700 (PDT) In-Reply-To: <08cf0b78-0fe6-1eda-383f-7d64466d6381@redhat.com> References: <3833782b96d47551263798eb78f448bd@polymtl.ca> <20180829154739.GB2521@adacore.com> <08cf0b78-0fe6-1eda-383f-7d64466d6381@redhat.com> From: Tim Newsome Date: Wed, 29 Aug 2018 20:13:00 -0000 Message-ID: Subject: Re: gdb requires watchpoints to fire after the write To: Pedro Alves Cc: Simon Marchi , Joel Brobecker , gdb Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00053.txt.bz2 Thanks everybody. That's really helpful. Tim On Wed, Aug 29, 2018 at 10:29 AM, Pedro Alves wrote: > On 08/29/2018 05:02 PM, Simon Marchi wrote: > > > I'm just confused by this condition: > > > > if (stopped_by_watchpoint > > && (target_have_steppable_watchpoint > > || gdbarch_have_nonsteppable_watchpoint (gdbarch))) > > > > I don't understand why we check for target_have_steppable_watchpoint OR > gdbarch_have_nonsteppable_watchpoint, they seem to mean opposite things. > > Yeah, it's confusing. > > GDB's current "model" is that there are three "kinds" of watchpoints, > wrt to when they trigger and how you can move past them. > > Those are: continuable, steppable, and non-steppable. > > Continuable watchpoints are like x86's -- those trigger after > the memory access's side effects are fully committed to memory. > I.e., they trap with the PC pointing at the next instruction > already. Continuing past such a watchpoint is doable > by just normally continuing, hence the name. > > Both steppable and nonsteppable watchpoints trap before > the memory access. I.e, the PC points at the instruction that > is accessing the memory. So GDB needs to single-step once past > the current instruction in order to make the access effective > and check whether the instruction's side effects change the > watched expression. > > Now, in order to step past that instruction, depending on > architecture, you can have two situations: > > - steppable watchpoints: you can single-step with the watchpoint still > armed, and the watchpoint won't trigger again. > > - non-steppable watchpoints: if you try to single-step with the watchpoint > still armed, you'd trap the watchpoint again and the thread wouldn't > make any progress. So GDB needs to temporarily remove the watchpoint > in order to step past it. > > So that's why we have all of target_have_continuable_watchpoint, > target_have_steppable_watchpoint and gdbarch_have_nonsteppable_watchpoint. > > Now, the main oddity is that from the definitions above, > we can tell that "continuable" is the same as "!steppable && > !nonsteppable", > which makes target_continuable_watchpoint redundant. > > Some targets do set "have_continuable_watchpoint" (like x86 > in x86-nat.h), but it doesn't seem like target_have_continuable_watchpoint > is checked anywhere nowadays. > > The target_have_steppable_watchpoint property is only set by ia64 > GNU/Linux > nowadays: > > /* The IA-64 architecture can step over a watch point (without > triggering it again) if the "dd" (data debug fault disable) bit > in the processor status word is set. > > This PSR bit is set in > ia64_linux_nat_target::stopped_by_watchpoint when the code there > has determined that a hardware watchpoint has indeed been hit. > The CPU will then be able to execute one instruction without > triggering a watchpoint. */ > bool have_steppable_watchpoint () { return 1; } > > There's of course also the oddity that target_have_continuable_watchpoint > and target_have_steppable_watchpoint are target methods, while > gdbarch_have_nonsteppable_watchpoint is a gdbarch method... > > We could most probably streamline all of this and come up with a better > design with some thought. See also the comment in mips-tdep.c: > > /* FIXME: cagney/2003-08-29: The macros target_have_steppable_ > watchpoint, > HAVE_NONSTEPPABLE_WATCHPOINT, and target_have_continuable_watchpoint > need to all be folded into the target vector. Since they are > being used as guards for target_stopped_by_watchpoint, why not have > target_stopped_by_watchpoint return the type of watchpoint that the > code > is sitting on? */ > set_gdbarch_have_nonsteppable_watchpoint (gdbarch, 1); > > Thanks, > Pedro Alves >