From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99862 invoked by alias); 30 Aug 2018 08:05:08 -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 98989 invoked by uid 89); 30 Aug 2018 08:03:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=invest, energy, intelligence X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Aug 2018 08:03:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id EED461173F9; Thu, 30 Aug 2018 04:03:55 -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 N-W7zijucwKV; Thu, 30 Aug 2018 04:03:55 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 18BB91173F7; Thu, 30 Aug 2018 04:03:55 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 6AB6986A78; Thu, 30 Aug 2018 10:03:53 +0200 (CEST) Date: Thu, 30 Aug 2018 08:05:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Pedro Alves , Simon Marchi , Tim Newsome , gdb Subject: Re: gdb requires watchpoints to fire after the write Message-ID: <20180830080353.GA2602@adacore.com> References: <3833782b96d47551263798eb78f448bd@polymtl.ca> <20180829154739.GB2521@adacore.com> <08cf0b78-0fe6-1eda-383f-7d64466d6381@redhat.com> <87ftywx54n.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ftywx54n.fsf@tromey.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2018-08/txt/msg00055.txt.bz2 > Pedro> Yeah, it's confusing. > > [... great explanation ... ] > > This would be great as comments in gdbarch.sh and target.h. > None of these things have comments currently. Agreed. I was going to send a patch doing so when I read Pedro's message, and then read this. I'm happy to do the patch, but don't want to start if Pedro is already on it. > Pedro> We could most probably streamline all of this and come up with a better > Pedro> design with some thought. See also the comment in mips-tdep.c: > > Pedro> /* FIXME: cagney/2003-08-29: The macros target_have_steppable_watchpoint, > Pedro> HAVE_NONSTEPPABLE_WATCHPOINT, and target_have_continuable_watchpoint > Pedro> need to all be folded into the target vector. Since they are > Pedro> being used as guards for target_stopped_by_watchpoint, why not have > Pedro> target_stopped_by_watchpoint return the type of watchpoint that the code > Pedro> is sitting on? */ > Pedro> set_gdbarch_have_nonsteppable_watchpoint (gdbarch, 1); > > I'm curious about why this should be in the target rather than in the > gdbarch. It seems like a property of the ISA. > > Is it possible for gdbserver to do the single-step itself, avoiding a > round trip? That was the only rationale I could think of. It might not be gdbserver itself, which I don't think should try to remain as minimalistic as possible in terms of this kind of "intelligence", but maybe some other stubs? For instance, a stub might be designed to be usable against another kind of debugger which might be expecting a certain type of behavior forcing the stub to have to do the single-step itself. (?) My perspective is that, if we don't have a concrete situation where this functionality should be a property of the target, and we find that it simplifies the code or avoids confusion to remove that target property, then let's. The obvious question then becomes - what to do with ia64-linux? Is this platform still in use and relevant enough for us to invest energy into redesigning the watchpoint support on this platform a bit? -- Joel