Message ID | 20230403145404.18548-1-mohamed.bouhaouel@intel.com |
---|---|
State | New |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C56EC3858C5E for <patchwork@sourceware.org>; Mon, 3 Apr 2023 14:54:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C56EC3858C5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1680533685; bh=rJP4Bebg+0nS9qeJftZuTK7jWG7p1JhR8KgUDpTNJRA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=lyaDron0SWo3X4bOEgloFm/zc0VKMwgUOfDAjBs+1GGVegJ7cD0qBMC3MmbpDJmKl 39Vz59JUhbgQEPX5Egl832hOr8fWbK0p3x+8a20+j/Cd6R6WghPBWBp9Sr4Up6uRUN qlELfBm2k/FAhyJpkuMdope9GTMMfr+ZGmHBoPwc= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by sourceware.org (Postfix) with ESMTPS id A471A3858D39 for <gdb-patches@sourceware.org>; Mon, 3 Apr 2023 14:54:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A471A3858D39 X-IronPort-AV: E=McAfee;i="6600,9927,10669"; a="325923126" X-IronPort-AV: E=Sophos;i="5.98,314,1673942400"; d="scan'208";a="325923126" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2023 07:54:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10669"; a="932058355" X-IronPort-AV: E=Sophos;i="5.98,314,1673942400"; d="scan'208";a="932058355" Received: from mbouhaou-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.53.136]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2023 07:54:18 -0700 To: gdb-patches@sourceware.org Subject: [PATCH 1/1] gdb, breakpoint: add a destructor to the watchpoint struct Date: Mon, 3 Apr 2023 16:54:04 +0200 Message-Id: <20230403145404.18548-1-mohamed.bouhaouel@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Mohamed Bouhaouel via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
[1/1] gdb, breakpoint: add a destructor to the watchpoint struct
|
|
Commit Message
Mohamed Bouhaouel
April 3, 2023, 2:54 p.m. UTC
Make sure to unlink the related breakpoint when the watchpoint instance is deleted. This prevents having a wp-related breakpoint that is linked to a NULL watchpoint (e.g. the watchpoint instance is being deleted when the 'watch' command fails). With the below scenario, having such a left out breakpoint will lead to a GDB hang, and this is due to an infinite loop when deleting all inferior breakpoints. Scenario: (gdb) awatch <VAR> Target does not support this type of hardware watchpoint. (gdb) rwatch <VAR> Target does not support this type of hardware watchpoint. (gdb) <continue the program until the end> >> HANG << Signed-off-by: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> --- gdb/breakpoint.c | 15 +++++++++++++++ gdb/breakpoint.h | 3 +++ 2 files changed, 18 insertions(+)
Comments
Mohamed Bouhaouel via Gdb-patches <gdb-patches@sourceware.org> writes: > Make sure to unlink the related breakpoint when the watchpoint instance > is deleted. This prevents having a wp-related breakpoint that is > linked to a NULL watchpoint (e.g. the watchpoint instance is being > deleted when the 'watch' command fails). With the below scenario, > having such a left out breakpoint will lead to a GDB hang, and this > is due to an infinite loop when deleting all inferior breakpoints. > > Scenario: > (gdb) awatch <VAR> > Target does not support this type of hardware watchpoint. > (gdb) rwatch <VAR> > Target does not support this type of hardware watchpoint. > (gdb) <continue the program until the end> > >> HANG << > Is it not possible to create a test case based on this scenario? Thanks, Andrew > Signed-off-by: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> > --- > gdb/breakpoint.c | 15 +++++++++++++++ > gdb/breakpoint.h | 3 +++ > 2 files changed, 18 insertions(+) > > diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c > index 7228acfd8fe..b9ddc85c30c 100644 > --- a/gdb/breakpoint.c > +++ b/gdb/breakpoint.c > @@ -9581,6 +9581,21 @@ break_range_command (const char *arg, int from_tty) > install_breakpoint (false, std::move (br), true); > } > > +/* See breakpoint.h. */ > + > +watchpoint::~watchpoint () > +{ > + /* Make sure to unlink the destroyed watchpoint from the related > + breakpoint ring. */ > + > + breakpoint *bpt = this; > + breakpoint *related = bpt; > + while (related->related_breakpoint != bpt) > + related = related->related_breakpoint; > + > + related->related_breakpoint = bpt->related_breakpoint; > +} > + > /* Return non-zero if EXP is verified as constant. Returned zero > means EXP is variable. Also the constant detection may fail for > some constant expressions and in such case still falsely return > diff --git a/gdb/breakpoint.h b/gdb/breakpoint.h > index 7c5cf3f2bef..4f19e42dd83 100644 > --- a/gdb/breakpoint.h > +++ b/gdb/breakpoint.h > @@ -933,6 +933,9 @@ struct watchpoint : public breakpoint > void print_recreate (struct ui_file *fp) const override; > bool explains_signal (enum gdb_signal) override; > > + /* Destructor for WATCHPOINT. */ > + virtual ~watchpoint (); > + > /* String form of exp to use for displaying to the user (malloc'd), > or NULL if none. */ > gdb::unique_xmalloc_ptr<char> exp_string; > -- > 2.25.1 > > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928
Thanks Andrew for your feedback. > > Scenario: > > (gdb) awatch <VAR> > > Target does not support this type of hardware watchpoint. > > (gdb) rwatch <VAR> > > Target does not support this type of hardware watchpoint. > > (gdb) <continue the program until the end> > > >> HANG << > > > > Is it not possible to create a test case based on this scenario? It is difficult to produce such scenario due to a weird behavior [1], which needs to be addressed as well. As a result, deleting watchpoints before resuming would hide the issue. [1] When the watch command fails, it is not possible to resume unless we explicitly delete the watchpoint. More details can be found here: https://sourceware.org/pipermail/gdb-patches/2023-March/198371.html) Kind regards, Mohamed > -----Original Message----- > From: Andrew Burgess <aburgess@redhat.com> > Sent: Tuesday, April 4, 2023 1:38 PM > To: Bouhaouel, Mohamed <mohamed.bouhaouel@intel.com>; gdb- > patches@sourceware.org > Subject: Re: [PATCH 1/1] gdb, breakpoint: add a destructor to the watchpoint > struct > > Mohamed Bouhaouel via Gdb-patches <gdb-patches@sourceware.org> > writes: > > > Make sure to unlink the related breakpoint when the watchpoint instance > > is deleted. This prevents having a wp-related breakpoint that is > > linked to a NULL watchpoint (e.g. the watchpoint instance is being > > deleted when the 'watch' command fails). With the below scenario, > > having such a left out breakpoint will lead to a GDB hang, and this > > is due to an infinite loop when deleting all inferior breakpoints. > > > > Scenario: > > (gdb) awatch <VAR> > > Target does not support this type of hardware watchpoint. > > (gdb) rwatch <VAR> > > Target does not support this type of hardware watchpoint. > > (gdb) <continue the program until the end> > > >> HANG << > > > > Is it not possible to create a test case based on this scenario? > > Thanks, > Andrew > > > Signed-off-by: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> > > --- > > gdb/breakpoint.c | 15 +++++++++++++++ > > gdb/breakpoint.h | 3 +++ > > 2 files changed, 18 insertions(+) > > > > diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c > > index 7228acfd8fe..b9ddc85c30c 100644 > > --- a/gdb/breakpoint.c > > +++ b/gdb/breakpoint.c > > @@ -9581,6 +9581,21 @@ break_range_command (const char *arg, int > from_tty) > > install_breakpoint (false, std::move (br), true); > > } > > > > +/* See breakpoint.h. */ > > + > > +watchpoint::~watchpoint () > > +{ > > + /* Make sure to unlink the destroyed watchpoint from the related > > + breakpoint ring. */ > > + > > + breakpoint *bpt = this; > > + breakpoint *related = bpt; > > + while (related->related_breakpoint != bpt) > > + related = related->related_breakpoint; > > + > > + related->related_breakpoint = bpt->related_breakpoint; > > +} > > + > > /* Return non-zero if EXP is verified as constant. Returned zero > > means EXP is variable. Also the constant detection may fail for > > some constant expressions and in such case still falsely return > > diff --git a/gdb/breakpoint.h b/gdb/breakpoint.h > > index 7c5cf3f2bef..4f19e42dd83 100644 > > --- a/gdb/breakpoint.h > > +++ b/gdb/breakpoint.h > > @@ -933,6 +933,9 @@ struct watchpoint : public breakpoint > > void print_recreate (struct ui_file *fp) const override; > > bool explains_signal (enum gdb_signal) override; > > > > + /* Destructor for WATCHPOINT. */ > > + virtual ~watchpoint (); > > + > > /* String form of exp to use for displaying to the user (malloc'd), > > or NULL if none. */ > > gdb::unique_xmalloc_ptr<char> exp_string; > > -- > > 2.25.1 > > > > Intel Deutschland GmbH > > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > > Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> > > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > > Chairperson of the Supervisory Board: Nicole Lau > > Registered Office: Munich > > Commercial Register: Amtsgericht Muenchen HRB 186928 Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
> > > Scenario: > > > (gdb) awatch <VAR> > > > Target does not support this type of hardware watchpoint. > > > (gdb) rwatch <VAR> > > > Target does not support this type of hardware watchpoint. > > > (gdb) <continue the program until the end> > > > >> HANG << > > > > > > > Is it not possible to create a test case based on this scenario? > > It is difficult to produce such scenario due to a weird behavior [1], > which needs to be addressed as well. As a result, deleting watchpoints > before resuming would hide the issue. I have been able to come up with a similar scenario that exposes the hang. - set can-use-hw-watchpoints 0 - stop inside a scope with local variables. - (gdb) awatch <LOCAL VAR> Can't set read/access watchpoint when hardware watchpoints are disabled. - (gdb) rwatch <LOCAL VAR> Can't set read/access watchpoint when hardware watchpoints are disabled. - (gdb) <continue the program until the end> >> HANG << I will add a regression test and submit a revised patch. Regards, Mohamed > -----Original Message----- > From: Bouhaouel, Mohamed > Sent: Tuesday, April 4, 2023 4:39 PM > To: Andrew Burgess <aburgess@redhat.com>; gdb-patches@sourceware.org > Subject: RE: [PATCH 1/1] gdb, breakpoint: add a destructor to the watchpoint > struct > > > Thanks Andrew for your feedback. > > > > Scenario: > > > (gdb) awatch <VAR> > > > Target does not support this type of hardware watchpoint. > > > (gdb) rwatch <VAR> > > > Target does not support this type of hardware watchpoint. > > > (gdb) <continue the program until the end> > > > >> HANG << > > > > > > > Is it not possible to create a test case based on this scenario? > > It is difficult to produce such scenario due to a weird behavior [1], > which needs to be addressed as well. As a result, deleting watchpoints > before resuming would hide the issue. > > > [1] When the watch command fails, it is not possible to resume > unless we explicitly delete the watchpoint. More details can be > found here: > https://sourceware.org/pipermail/gdb-patches/2023-March/198371.html) > > Kind regards, > Mohamed > > > > > -----Original Message----- > > From: Andrew Burgess <aburgess@redhat.com> > > Sent: Tuesday, April 4, 2023 1:38 PM > > To: Bouhaouel, Mohamed <mohamed.bouhaouel@intel.com>; gdb- > > patches@sourceware.org > > Subject: Re: [PATCH 1/1] gdb, breakpoint: add a destructor to the watchpoint > > struct > > > > Mohamed Bouhaouel via Gdb-patches <gdb-patches@sourceware.org> > > writes: > > > > > Make sure to unlink the related breakpoint when the watchpoint instance > > > is deleted. This prevents having a wp-related breakpoint that is > > > linked to a NULL watchpoint (e.g. the watchpoint instance is being > > > deleted when the 'watch' command fails). With the below scenario, > > > having such a left out breakpoint will lead to a GDB hang, and this > > > is due to an infinite loop when deleting all inferior breakpoints. > > > > > > Scenario: > > > (gdb) awatch <VAR> > > > Target does not support this type of hardware watchpoint. > > > (gdb) rwatch <VAR> > > > Target does not support this type of hardware watchpoint. > > > (gdb) <continue the program until the end> > > > >> HANG << > > > > > > > Is it not possible to create a test case based on this scenario? > > > > Thanks, > > Andrew > > > > > Signed-off-by: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> > > > --- > > > gdb/breakpoint.c | 15 +++++++++++++++ > > > gdb/breakpoint.h | 3 +++ > > > 2 files changed, 18 insertions(+) > > > > > > diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c > > > index 7228acfd8fe..b9ddc85c30c 100644 > > > --- a/gdb/breakpoint.c > > > +++ b/gdb/breakpoint.c > > > @@ -9581,6 +9581,21 @@ break_range_command (const char *arg, int > > from_tty) > > > install_breakpoint (false, std::move (br), true); > > > } > > > > > > +/* See breakpoint.h. */ > > > + > > > +watchpoint::~watchpoint () > > > +{ > > > + /* Make sure to unlink the destroyed watchpoint from the related > > > + breakpoint ring. */ > > > + > > > + breakpoint *bpt = this; > > > + breakpoint *related = bpt; > > > + while (related->related_breakpoint != bpt) > > > + related = related->related_breakpoint; > > > + > > > + related->related_breakpoint = bpt->related_breakpoint; > > > +} > > > + > > > /* Return non-zero if EXP is verified as constant. Returned zero > > > means EXP is variable. Also the constant detection may fail for > > > some constant expressions and in such case still falsely return > > > diff --git a/gdb/breakpoint.h b/gdb/breakpoint.h > > > index 7c5cf3f2bef..4f19e42dd83 100644 > > > --- a/gdb/breakpoint.h > > > +++ b/gdb/breakpoint.h > > > @@ -933,6 +933,9 @@ struct watchpoint : public breakpoint > > > void print_recreate (struct ui_file *fp) const override; > > > bool explains_signal (enum gdb_signal) override; > > > > > > + /* Destructor for WATCHPOINT. */ > > > + virtual ~watchpoint (); > > > + > > > /* String form of exp to use for displaying to the user (malloc'd), > > > or NULL if none. */ > > > gdb::unique_xmalloc_ptr<char> exp_string; > > > -- > > > 2.25.1 > > > > > > Intel Deutschland GmbH > > > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > > > Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> > > > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > > > Chairperson of the Supervisory Board: Nicole Lau > > > Registered Office: Munich > > > Commercial Register: Amtsgericht Muenchen HRB 186928 Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
>>>>> Mohamed Bouhaouel via Gdb-patches <gdb-patches@sourceware.org> writes: > + /* Destructor for WATCHPOINT. */ > + virtual ~watchpoint (); I don't think the 'virtual' is needed here. Tom
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c index 7228acfd8fe..b9ddc85c30c 100644 --- a/gdb/breakpoint.c +++ b/gdb/breakpoint.c @@ -9581,6 +9581,21 @@ break_range_command (const char *arg, int from_tty) install_breakpoint (false, std::move (br), true); } +/* See breakpoint.h. */ + +watchpoint::~watchpoint () +{ + /* Make sure to unlink the destroyed watchpoint from the related + breakpoint ring. */ + + breakpoint *bpt = this; + breakpoint *related = bpt; + while (related->related_breakpoint != bpt) + related = related->related_breakpoint; + + related->related_breakpoint = bpt->related_breakpoint; +} + /* Return non-zero if EXP is verified as constant. Returned zero means EXP is variable. Also the constant detection may fail for some constant expressions and in such case still falsely return diff --git a/gdb/breakpoint.h b/gdb/breakpoint.h index 7c5cf3f2bef..4f19e42dd83 100644 --- a/gdb/breakpoint.h +++ b/gdb/breakpoint.h @@ -933,6 +933,9 @@ struct watchpoint : public breakpoint void print_recreate (struct ui_file *fp) const override; bool explains_signal (enum gdb_signal) override; + /* Destructor for WATCHPOINT. */ + virtual ~watchpoint (); + /* String form of exp to use for displaying to the user (malloc'd), or NULL if none. */ gdb::unique_xmalloc_ptr<char> exp_string;