Message ID | 77978648-c391-0011-6c03-c7fd38429914@embecosm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 65086 invoked by alias); 24 Sep 2018 11:36:14 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 65073 invoked by uid 89); 24 Sep 2018 11:36:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=letters, Show, prefixes, timing X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Sep 2018 11:36:11 +0000 Received: by mail-wr1-f68.google.com with SMTP id e1-v6so19328419wrt.3 for <gdb-patches@sourceware.org>; Mon, 24 Sep 2018 04:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=U7OebzXIxMBZfn+pJYwCuafXnA20GU7DNs0L1mp8n+M=; b=dwSS0cWOwdBg3r6vM5VrT/ITuRvD7JoSGI+qO16Mic1Q6K6ogI9uY9tAIwtTorA1YB fyP5LbGy4M3AaHT0Oyh3nDUNwKLdbT2W8DB+NwdDMJualWJsE7hpX9gGGcrQjOhrgsIN Z4MxQfWa8GBiEQZX8JV5zkDVBrAWWBd4y5TNfXgIDgML4Hn7OKqA0hY8O3QS1QxYoFLD lO5TP/N9gPEBOV13LcKqS6tXtWhvUX38NNGCvwkjuvWcf27bw7TsUi4Fhzclz2K4Ia4m sENZyPNqfME6gVihXkPTSxuI8R+lfhAmZwg7ffW5bZmIZ15T0edTZr264+Xom8sxpIzB 5Wfw== Return-Path: <craig.blackmore@embecosm.com> Received: from ?IPv6:2a02:390:741d:1:d4b2:8065:3bc7:d2eb? ([2a02:390:741d:1:d4b2:8065:3bc7:d2eb]) by smtp.gmail.com with ESMTPSA id b74-v6sm22643429wma.8.2018.09.24.04.36.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Sep 2018 04:36:08 -0700 (PDT) Subject: Re: [PATCH] RISC-V: enable have_nonsteppable_watchpoint by default To: Andrew Burgess <andrew.burgess@embecosm.com> Cc: gdb-patches@sourceware.org References: <c83e39fb-b1e8-cc67-85b5-c7cc66197078@embecosm.com> <20180917103409.GJ5952@embecosm.com> From: Craig Blackmore <craig.blackmore@embecosm.com> Openpgp: preference=signencrypt Message-ID: <77978648-c391-0011-6c03-c7fd38429914@embecosm.com> Date: Mon, 24 Sep 2018 12:36:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180917103409.GJ5952@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable |
Commit Message
Craig Blackmore
Sept. 24, 2018, 11:36 a.m. UTC
On 17/09/18 11:34, Andrew Burgess wrote: > * Craig Blackmore <craig.blackmore@embecosm.com> [2018-09-16 01:13:08 +0100]: > >> The RISC-V debug spec 0.13 recommends that write triggers fire before >> the write is committed. If the target follows this behaviour, then >> have_nonsteppable_watchpoint needs to be set to 1 so that GDB will step >> over the watchpoint before checking if the value has changed. >> >> This patch adds a setshow for have_nonsteppable_watchpoint which defaults >> to 1 to match the recommended behaviour. If a target does not follow >> this timing, then 'set riscv have_nonsteppable_watchpoint 0' will need >> to be issued on the command line. > Thanks for this. Just a few minor formatting issues which I've > pointed out below. > > Thanks, > Andrew > >> >> gdb/ChangeLog: >> >> * riscv-tdep.c (set_have_nonsteppable_watchpoint): add >> callback for 'set riscv have_nonsteppable_watchpoint' >> (riscv_gdbarch_init): initialise gdbarch setting for >> have_nonesteppable_watchpoint > Proper sentences in ChangeLogs please, capital letters and > full-stops. > >> --- >> >> diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c >> index 254914c9c7..8f301d8b01 100644 >> --- a/gdb/riscv-tdep.c >> +++ b/gdb/riscv-tdep.c >> @@ -226,6 +226,20 @@ show_use_compressed_breakpoints (struct ui_file *file, int from_tty, >> "to %s%s.\n"), value, additional_info); >> } >> >> +static int riscv_have_nonsteppable_watchpoint = 1; > You need to add a comment for this variable. > >> + >> +/* The set callback for 'set riscv have-nonsteppable-watchpoint'. */ > Two whitespace after the full-stop and before the comment close please. > >> + >> +static void >> +set_have_nonsteppable_watchpoint (const char *args, int from_tty, >> + struct cmd_list_element *c) >> +{ >> + struct gdbarch *gdbarch = target_gdbarch (); >> + >> + set_gdbarch_have_nonsteppable_watchpoint (gdbarch, >> + riscv_have_nonsteppable_watchpoint); >> +} >> + >> /* The set and show lists for 'set riscv' and 'show riscv' prefixes. */ >> >> static struct cmd_list_element *setriscvcmdlist = NULL; >> @@ -2736,6 +2750,8 @@ riscv_gdbarch_init (struct gdbarch_info info, >> set_gdbarch_return_value (gdbarch, riscv_return_value); >> set_gdbarch_breakpoint_kind_from_pc (gdbarch, riscv_breakpoint_kind_from_pc); >> set_gdbarch_sw_breakpoint_from_kind (gdbarch, riscv_sw_breakpoint_from_kind); >> + set_gdbarch_have_nonsteppable_watchpoint (gdbarch, >> + riscv_have_nonsteppable_watchpoint); >> >> /* Register architecture. */ >> set_gdbarch_num_regs (gdbarch, RISCV_LAST_REGNUM + 1); >> @@ -2980,4 +2996,20 @@ can be used."), >> show_use_compressed_breakpoints, >> &setriscvcmdlist, >> &showriscvcmdlist); >> + >> + add_setshow_boolean_cmd ("have-nonsteppable-watchpoint", no_class, >> + &riscv_have_nonsteppable_watchpoint, >> + _("\ >> +Set whether debugger must step over hardware watchpoints"), >> + _("\ >> +Show whether debugger must step over hardware watchpoints"), >> + _("\ >> +The RISC-V debug spec recommends that hardware write watchpoints fire before\n\ >> +the write is committed, in which case, GDB must step over the watchpoint\n\ >> +before checking the old and new values. Set this option to 1 (default) for\n\ > Two whitespace after full-stop again please. > >> +targets that follow this behaviour, otherwise set to 0."), > As this is a boolean command can you replace references to 1 and 0 > both here and in the commit message with on and off. > >> + set_have_nonsteppable_watchpoint, >> + NULL, > You need to implement the show method too to allow for > internationalisation. > >> + &setriscvcmdlist, >> + &showriscvcmdlist); >> } >> >> Thanks for these comments, I have updated the patch accordingly. --- The RISC-V debug spec 0.13 recommends that write triggers fire before the write is committed. If the target follows this behaviour, then have_nonsteppable_watchpoint needs to be set to 'on' so that GDB will step over the watchpoint before checking if the value has changed. This patch adds a setshow for have_nonsteppable_watchpoint which defaults to 'on' to match the recommended behaviour. If a target does not follow this timing, then 'set riscv have_nonsteppable_watchpoint off' will need to be issued on the command line. gdb/ChangeLog: * riscv-tdep.c (set_have_nonsteppable_watchpoint): Add callback for 'set riscv have_nonsteppable_watchpoint'. (show_have_nonsteppable_watchpoint): Add callback for 'show riscv have_nonsteppable_watchpoint'. (riscv_gdbarch_init): Initialise gdbarch setting for have_nonesteppable_watchpoint. ---
Comments
Hi Craig, hi Andrew, > --- > > The RISC-V debug spec 0.13 recommends that write triggers fire before the > write is committed. If the target follows this behaviour, then > have_nonsteppable_watchpoint needs to be set to 'on' so that GDB will step > over the watchpoint before checking if the value has changed. > > This patch adds a setshow for have_nonsteppable_watchpoint which defaults > to 'on' to match the recommended behaviour. If a target does not follow > this timing, then 'set riscv have_nonsteppable_watchpoint off' will need > to be issued on the command line. > > gdb/ChangeLog: > > * riscv-tdep.c (set_have_nonsteppable_watchpoint): Add callback > for 'set riscv have_nonsteppable_watchpoint'. > (show_have_nonsteppable_watchpoint): Add callback for > 'show riscv have_nonsteppable_watchpoint'. > (riscv_gdbarch_init): Initialise gdbarch setting for > have_nonesteppable_watchpoint. I assume this patch is waiting for review from Andrew? I took a look, since I am interested in it as well. Here are my comments. You forgot to document the introduction of riscv_have_nonsteppable_watchpoint in your ChangeLog above; eg: * riscv-tdep.c (riscv_have_nonsteppable_watchpoint): New static global. You also forgot to document that you're adding new subcommands. The rest looks good to me. > --- > > diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c > index 254914c..857c5d1 100644 > --- a/gdb/riscv-tdep.c > +++ b/gdb/riscv-tdep.c > @@ -226,6 +226,36 @@ show_use_compressed_breakpoints (struct ui_file *file, int from_tty, > "to %s%s.\n"), value, additional_info); > } > > +/* Controls whether the debugger should step over hardware watchpoints before > + checking if the watched variable has changed. If true, then the debugger > + will step over the watchpoint. */ > + > +static int riscv_have_nonsteppable_watchpoint = 1; > + > +/* The set callback for 'set riscv have-nonsteppable-watchpoint'. */ > + > +static void > +set_have_nonsteppable_watchpoint (const char *args, int from_tty, > + struct cmd_list_element *c) > +{ > + struct gdbarch *gdbarch = target_gdbarch (); > + > + set_gdbarch_have_nonsteppable_watchpoint (gdbarch, > + riscv_have_nonsteppable_watchpoint); > +} > + > +/* The show callback for 'show riscv have-nonsteppable-watchpoint'. */ > + > +static void > +show_have_nonsteppable_watchpoint (struct ui_file *file, int from_tty, > + struct cmd_list_element *c, > + const char *value) > +{ > + fprintf_filtered (file, > + _("Debugger must step over hardware watchpoints is set to " > + "%s.\n"), value); > +} > + > /* The set and show lists for 'set riscv' and 'show riscv' prefixes. */ > > static struct cmd_list_element *setriscvcmdlist = NULL; > @@ -2736,6 +2766,8 @@ riscv_gdbarch_init (struct gdbarch_info info, > set_gdbarch_return_value (gdbarch, riscv_return_value); > set_gdbarch_breakpoint_kind_from_pc (gdbarch, riscv_breakpoint_kind_from_pc); > set_gdbarch_sw_breakpoint_from_kind (gdbarch, riscv_sw_breakpoint_from_kind); > + set_gdbarch_have_nonsteppable_watchpoint (gdbarch, > + riscv_have_nonsteppable_watchpoint); > > /* Register architecture. */ > set_gdbarch_num_regs (gdbarch, RISCV_LAST_REGNUM + 1); > @@ -2980,4 +3012,20 @@ can be used."), > show_use_compressed_breakpoints, > &setriscvcmdlist, > &showriscvcmdlist); > + > + add_setshow_boolean_cmd ("have-nonsteppable-watchpoint", no_class, > + &riscv_have_nonsteppable_watchpoint, > + _("\ > +Set whether debugger must step over hardware watchpoints"), > + _("\ > +Show whether debugger must step over hardware watchpoints"), > + _("\ > +The RISC-V debug spec recommends that hardware write watchpoints fire before\n\ > +the write is committed, in which case, GDB must step over the watchpoint\n\ > +before checking the old and new values. Set this option to 'on' (default)\n\ > +for targets that follow this behaviour, otherwise set to 'off'."), > + set_have_nonsteppable_watchpoint, > + show_have_nonsteppable_watchpoint, > + &setriscvcmdlist, > + &showriscvcmdlist); > } >
* Joel Brobecker <brobecker@adacore.com> [2018-10-03 15:37:03 -0700]: > Hi Craig, hi Andrew, > > > --- > > > > The RISC-V debug spec 0.13 recommends that write triggers fire before the > > write is committed. If the target follows this behaviour, then > > have_nonsteppable_watchpoint needs to be set to 'on' so that GDB will step > > over the watchpoint before checking if the value has changed. > > > > This patch adds a setshow for have_nonsteppable_watchpoint which defaults > > to 'on' to match the recommended behaviour. If a target does not follow > > this timing, then 'set riscv have_nonsteppable_watchpoint off' will need > > to be issued on the command line. > > > > gdb/ChangeLog: > > > > * riscv-tdep.c (set_have_nonsteppable_watchpoint): Add callback > > for 'set riscv have_nonsteppable_watchpoint'. > > (show_have_nonsteppable_watchpoint): Add callback for > > 'show riscv have_nonsteppable_watchpoint'. > > (riscv_gdbarch_init): Initialise gdbarch setting for > > have_nonesteppable_watchpoint. > > I assume this patch is waiting for review from Andrew? No, I was hoping for some feedback from Pedro, he commented in this post: https://sourceware.org/ml/gdb-patches/2018-09/msg00570.html that he wasn't happy with the approach Craig took. He would like to see the switching done automatically from the target description. In this post: https://sourceware.org/ml/gdb-patches/2018-09/msg00572.html I agree with Pedro, but take the position that as riscv doesn't currently have any target description support (I hope to work on some of this soon) then I'd like this patch to go in as it is and improve on it later. However, as Pedro is a global maintainer, I don't feel I can OK the patch with his negative feedback outstanding... Thanks, Andrew > > I took a look, since I am interested in it as well. Here are my > comments. > > You forgot to document the introduction of riscv_have_nonsteppable_watchpoint > in your ChangeLog above; eg: > > * riscv-tdep.c (riscv_have_nonsteppable_watchpoint): New static > global. > > You also forgot to document that you're adding new subcommands. > > The rest looks good to me. > > > --- > > > > diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c > > index 254914c..857c5d1 100644 > > --- a/gdb/riscv-tdep.c > > +++ b/gdb/riscv-tdep.c > > @@ -226,6 +226,36 @@ show_use_compressed_breakpoints (struct ui_file *file, int from_tty, > > "to %s%s.\n"), value, additional_info); > > } > > > > +/* Controls whether the debugger should step over hardware watchpoints before > > + checking if the watched variable has changed. If true, then the debugger > > + will step over the watchpoint. */ > > + > > +static int riscv_have_nonsteppable_watchpoint = 1; > > + > > +/* The set callback for 'set riscv have-nonsteppable-watchpoint'. */ > > + > > +static void > > +set_have_nonsteppable_watchpoint (const char *args, int from_tty, > > + struct cmd_list_element *c) > > +{ > > + struct gdbarch *gdbarch = target_gdbarch (); > > + > > + set_gdbarch_have_nonsteppable_watchpoint (gdbarch, > > + riscv_have_nonsteppable_watchpoint); > > +} > > + > > +/* The show callback for 'show riscv have-nonsteppable-watchpoint'. */ > > + > > +static void > > +show_have_nonsteppable_watchpoint (struct ui_file *file, int from_tty, > > + struct cmd_list_element *c, > > + const char *value) > > +{ > > + fprintf_filtered (file, > > + _("Debugger must step over hardware watchpoints is set to " > > + "%s.\n"), value); > > +} > > + > > /* The set and show lists for 'set riscv' and 'show riscv' prefixes. */ > > > > static struct cmd_list_element *setriscvcmdlist = NULL; > > @@ -2736,6 +2766,8 @@ riscv_gdbarch_init (struct gdbarch_info info, > > set_gdbarch_return_value (gdbarch, riscv_return_value); > > set_gdbarch_breakpoint_kind_from_pc (gdbarch, riscv_breakpoint_kind_from_pc); > > set_gdbarch_sw_breakpoint_from_kind (gdbarch, riscv_sw_breakpoint_from_kind); > > + set_gdbarch_have_nonsteppable_watchpoint (gdbarch, > > + riscv_have_nonsteppable_watchpoint); > > > > /* Register architecture. */ > > set_gdbarch_num_regs (gdbarch, RISCV_LAST_REGNUM + 1); > > @@ -2980,4 +3012,20 @@ can be used."), > > show_use_compressed_breakpoints, > > &setriscvcmdlist, > > &showriscvcmdlist); > > + > > + add_setshow_boolean_cmd ("have-nonsteppable-watchpoint", no_class, > > + &riscv_have_nonsteppable_watchpoint, > > + _("\ > > +Set whether debugger must step over hardware watchpoints"), > > + _("\ > > +Show whether debugger must step over hardware watchpoints"), > > + _("\ > > +The RISC-V debug spec recommends that hardware write watchpoints fire before\n\ > > +the write is committed, in which case, GDB must step over the watchpoint\n\ > > +before checking the old and new values. Set this option to 'on' (default)\n\ > > +for targets that follow this behaviour, otherwise set to 'off'."), > > + set_have_nonsteppable_watchpoint, > > + show_have_nonsteppable_watchpoint, > > + &setriscvcmdlist, > > + &showriscvcmdlist); > > } > > > > -- > Joel
On 10/08/2018 10:58 AM, Andrew Burgess wrote: > * Joel Brobecker <brobecker@adacore.com> [2018-10-03 15:37:03 -0700]: > >> Hi Craig, hi Andrew, >> >>> --- >>> >>> The RISC-V debug spec 0.13 recommends that write triggers fire before the >>> write is committed. If the target follows this behaviour, then >>> have_nonsteppable_watchpoint needs to be set to 'on' so that GDB will step >>> over the watchpoint before checking if the value has changed. >>> >>> This patch adds a setshow for have_nonsteppable_watchpoint which defaults >>> to 'on' to match the recommended behaviour. If a target does not follow >>> this timing, then 'set riscv have_nonsteppable_watchpoint off' will need >>> to be issued on the command line. >>> >>> gdb/ChangeLog: >>> >>> * riscv-tdep.c (set_have_nonsteppable_watchpoint): Add callback >>> for 'set riscv have_nonsteppable_watchpoint'. >>> (show_have_nonsteppable_watchpoint): Add callback for >>> 'show riscv have_nonsteppable_watchpoint'. >>> (riscv_gdbarch_init): Initialise gdbarch setting for >>> have_nonesteppable_watchpoint. >> >> I assume this patch is waiting for review from Andrew? > > No, I was hoping for some feedback from Pedro, he commented in this > post: > https://sourceware.org/ml/gdb-patches/2018-09/msg00570.html Sorry, replied now. > that he wasn't happy with the approach Craig took. He would like to > see the switching done automatically from the target description. In > this post: > https://sourceware.org/ml/gdb-patches/2018-09/msg00572.html > > I agree with Pedro, but take the position that as riscv doesn't > currently have any target description support (I hope to work on some > of this soon) then I'd like this patch to go in as it is and improve > on it later. > > However, as Pedro is a global maintainer, I don't feel I can OK the > patch with his negative feedback outstanding... Sorry, I don't mean to hold people back, but indeed I haven't managed to be very responsive in the last few weeks... There are a number of issues with the patch as is. Off hand: #1 - Missing NEWS. #2 - Missing manual/docs change. #3 - set_have_nonsteppable_watchpoint works on whatever's the current inferior's gdbarch, so it means that if you're running a --enable-targets=all gdb against something non-RISC-V, the command will affect that architecture. #4 - OTOH, the command is documented as a RISC-V command. But it's in the global "set" namespace right? Not something like "set riscv have-nonsteppable-watchpoint"? #5 - I think "have-nonsteppable-watchpoint" is a bad user-facing name. It is exposing outdated gdb-internal lingo ("nonsteppable"). The property in question is whether the watchpoint triggers before or after the instruction is executed. How that translates to "nonsteppable" for users is going to be quite cryptic. The above, keeping in mind that it'd be much better for GDB to figure this stuff out itself, and coupled with the fact that I'm not sure whether there are in fact implementations of riscv that trigger watchpoints after the write, makes me wonder, do we really need this? Thanks, Pedro Alves
> [...] coupled with the fact that I'm not sure > whether there are in fact implementations of riscv that trigger > watchpoints after the write, makes me wonder, do we really need this? Actually - that's a very good point. Do we know of any architecture where the watchpoint triggers after the write?
> On Oct 8, 2018, at 10:25 AM, Joel Brobecker <brobecker@adacore.com> wrote: > >> [...] coupled with the fact that I'm not sure >> whether there are in fact implementations of riscv that trigger >> watchpoints after the write, makes me wonder, do we really need this? > > Actually - that's a very good point. Do we know of any architecture > where the watchpoint triggers after the write? I think MIPS is one. The documentation is not entirely clear but that's what I remember from using it. paul
On 10/08/2018 03:37 PM, Paul Koning wrote: > > >> On Oct 8, 2018, at 10:25 AM, Joel Brobecker <brobecker@adacore.com> wrote: >> >>> [...] coupled with the fact that I'm not sure >>> whether there are in fact implementations of riscv that trigger >>> watchpoints after the write, makes me wonder, do we really need this? >> >> Actually - that's a very good point. Do we know of any architecture >> where the watchpoint triggers after the write? > > 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. Thanks, Pedro Alves
On Okt 08 2018, Paul Koning <paulkoning@comcast.net> wrote:
> I think MIPS is one. The documentation is not entirely clear but that's what I remember from using it.
According to mips-tdep.c, mips is nonsteppable.
Andreas.
> > 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. 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.
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. 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. >
> On Oct 9, 2018, at 1:20 PM, Craig Blackmore <craig.blackmore@embecosm.com> wrote: > > > > 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 missed that the question was specific to RISC-V. If the spec says that timing is up to the implementation, that seems to mean GDB can't rely on the break occurring before the write -- the fact that current implementations do so isn't sufficient if later implementation are allowed to differ. I assume GDB cares which it is, which suggests that the implementation has to tell GDB which flavor of write watchpoint it has. paul
* Craig Blackmore <craig.blackmore@embecosm.com> [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. > > > >
diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c index 254914c..857c5d1 100644 --- a/gdb/riscv-tdep.c +++ b/gdb/riscv-tdep.c @@ -226,6 +226,36 @@ show_use_compressed_breakpoints (struct ui_file *file, int from_tty, "to %s%s.\n"), value, additional_info); } +/* Controls whether the debugger should step over hardware watchpoints before + checking if the watched variable has changed. If true, then the debugger + will step over the watchpoint. */ + +static int riscv_have_nonsteppable_watchpoint = 1; + +/* The set callback for 'set riscv have-nonsteppable-watchpoint'. */ + +static void +set_have_nonsteppable_watchpoint (const char *args, int from_tty, + struct cmd_list_element *c) +{ + struct gdbarch *gdbarch = target_gdbarch (); + + set_gdbarch_have_nonsteppable_watchpoint (gdbarch, + riscv_have_nonsteppable_watchpoint); +} + +/* The show callback for 'show riscv have-nonsteppable-watchpoint'. */ + +static void +show_have_nonsteppable_watchpoint (struct ui_file *file, int from_tty, + struct cmd_list_element *c, + const char *value) +{ + fprintf_filtered (file, + _("Debugger must step over hardware watchpoints is set to " + "%s.\n"), value); +} + /* The set and show lists for 'set riscv' and 'show riscv' prefixes. */ static struct cmd_list_element *setriscvcmdlist = NULL; @@ -2736,6 +2766,8 @@ riscv_gdbarch_init (struct gdbarch_info info, set_gdbarch_return_value (gdbarch, riscv_return_value); set_gdbarch_breakpoint_kind_from_pc (gdbarch, riscv_breakpoint_kind_from_pc); set_gdbarch_sw_breakpoint_from_kind (gdbarch, riscv_sw_breakpoint_from_kind); + set_gdbarch_have_nonsteppable_watchpoint (gdbarch, + riscv_have_nonsteppable_watchpoint); /* Register architecture. */ set_gdbarch_num_regs (gdbarch, RISCV_LAST_REGNUM + 1); @@ -2980,4 +3012,20 @@ can be used."), show_use_compressed_breakpoints, &setriscvcmdlist, &showriscvcmdlist); + + add_setshow_boolean_cmd ("have-nonsteppable-watchpoint", no_class, + &riscv_have_nonsteppable_watchpoint, + _("\ +Set whether debugger must step over hardware watchpoints"), + _("\ +Show whether debugger must step over hardware watchpoints"), + _("\ +The RISC-V debug spec recommends that hardware write watchpoints fire before\n\ +the write is committed, in which case, GDB must step over the watchpoint\n\ +before checking the old and new values. Set this option to 'on' (default)\n\ +for targets that follow this behaviour, otherwise set to 'off'."), + set_have_nonsteppable_watchpoint, + show_have_nonsteppable_watchpoint, + &setriscvcmdlist, + &showriscvcmdlist); }