Message ID | 20221018141733.29298-1-simon.marchi@efficios.com |
---|---|
State | Committed |
Commit | 9454c9ce88b25646d279feed329c9cdba69b4905 |
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 6602838582AD for <patchwork@sourceware.org>; Tue, 18 Oct 2022 14:18:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6602838582AD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666102682; bh=sCre/FudsoqCubfXJZI9i8V4a3u/yMKf46+DqqNIRF0=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=GhY4XTRF+jJ6tqRIqKywe8fEU7erLAEmegnqdY5dhiQynDCDnPlyD+F4ItqcZR534 JmX8YcUqgMczWwRap6rIqeQJickBKdtCOee0PyFPTIVl68beX7xMgCMcgO5A2ArCGg GBkQobjMTec9Wpz/1biw0BGjGHGI+HvBj3K04C6c= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from alt32.smtp-out.videotron.ca (alt32.smtp-out.videotron.ca [24.53.0.21]) by sourceware.org (Postfix) with ESMTPS id 748E93858027 for <gdb-patches@sourceware.org>; Tue, 18 Oct 2022 14:17:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 748E93858027 Received: from localhost.localdomain ([74.56.249.162]) by Videotron with ESMTP id knPSoUIItLykPknPSohknt; Tue, 18 Oct 2022 10:17:37 -0400 X-Authority-Analysis: v=2.4 cv=Ys1s+6UX c=1 sm=1 tr=0 ts=634eb581 a=vTEE2W6FS0436lLiwMOoNg==:117 a=vTEE2W6FS0436lLiwMOoNg==:17 a=0Lei0MbLZxCwy9XTfUEA:9 To: gdb-patches@sourceware.org Subject: [PATCH] gdb: check for groups with duplicate names in reggroups:add Date: Tue, 18 Oct 2022 10:17:33 -0400 Message-Id: <20221018141733.29298-1-simon.marchi@efficios.com> X-Mailer: git-send-email 2.38.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfDDgUVbPLbfVBQZrXpLTZfuhl+L+Xq1io3XMCb+zedAANl7Jjmar1FjIEvtIJVhIHMyxD6BpUgww7ZqYgR9pa14vDNINbKTeFHENr35JH8TyZq4oQWfs dsrSAs0NZU/5u+cx8srD7547m9Bk68BIIEAf5mA9YtZgR3wEAOHv01SoCsZK4h3637fsVuSt/ieDBC7bPy30nKgmf8tgB0Zcv2IdBnxYyaXCoVWlXu3cn9wU X6yPIYhwmVcnUWR2g3P9cA== X-Spam-Status: No, score=-1174.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_SOFTFAIL, 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: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Simon Marchi <simon.marchi@efficios.com> Cc: Simon Marchi <simon.marchi@efficios.com> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
gdb: check for groups with duplicate names in reggroups:add
|
|
Commit Message
Simon Marchi
Oct. 18, 2022, 2:17 p.m. UTC
In the downstream ROCm GDB port, we would create multiple register groups with duplicate names. While it did not really hurt, it certainly wasn't the intent. And I don't think it ever makes sense to do so. To catch these, change the assert in reggroups::add to check for duplicate names. It's no longer necessary to check for duplicate reggroup pointers, because adding the same group twice would be caught by the duplicate name check. Change-Id: Id216a58acf91f1b314d3cba2d02de73656f8851d --- gdb/reggroups.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
Comments
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> In the downstream ROCm GDB port, we would create multiple register
Simon> groups with duplicate names. While it did not really hurt, it certainly
Simon> wasn't the intent. And I don't think it ever makes sense to do so.
Simon> To catch these, change the assert in reggroups::add to check for
Simon> duplicate names. It's no longer necessary to check for duplicate
Simon> reggroup pointers, because adding the same group twice would be caught
Simon> by the duplicate name check.
I haven't looked but would it be possible for malformed XML from the
target to trigger this assert?
Tom
On 10/18/22 14:42, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes: > > Simon> In the downstream ROCm GDB port, we would create multiple register > Simon> groups with duplicate names. While it did not really hurt, it certainly > Simon> wasn't the intent. And I don't think it ever makes sense to do so. > > Simon> To catch these, change the assert in reggroups::add to check for > Simon> duplicate names. It's no longer necessary to check for duplicate > Simon> reggroup pointers, because adding the same group twice would be caught > Simon> by the duplicate name check. > > I haven't looked but would it be possible for malformed XML from the > target to trigger this assert? > > Tom I don't think so, because the target description support code creates the groups as it finds them while iterating registers. It only creates a group if it doesn't exist already: https://gitlab.com/gnutools/binutils-gdb/-/blob/152cc35ebff44eb06a00364ca1dbcf5fca6772b4/gdb/target-descriptions.c#L1124-1125 In other words, the XML tdesc doesn't have a list of groups, where if a group was duplicated, it could trigger this assert. Simon
Simon> I don't think so, because the target description support code creates Simon> the groups as it finds them while iterating registers. Thanks, in that case this seems like a good idea to me. Tom
On 10/18/22 15:01, Tom Tromey wrote: > Simon> I don't think so, because the target description support code creates > Simon> the groups as it finds them while iterating registers. > > Thanks, in that case this seems like a good idea to me. > > Tom I am asking, because these things are still new, so better safe than sorry: are you fine with me adding your Approved-By? Simon
Simon> I am asking, because these things are still new, so better safe than Simon> sorry: are you fine with me adding your Approved-By? Yes, definitely. thanks, Tom
On 2022-10-18 21:54, Tom Tromey wrote: > Simon> I am asking, because these things are still new, so better safe than > Simon> sorry: are you fine with me adding your Approved-By? > > Yes, definitely. > > thanks, > Tom Thanks, pushed. Simon
diff --git a/gdb/reggroups.c b/gdb/reggroups.c index 8e4af303c545..a012bf085265 100644 --- a/gdb/reggroups.c +++ b/gdb/reggroups.c @@ -71,8 +71,13 @@ struct reggroups void add (const reggroup *group) { gdb_assert (group != nullptr); - gdb_assert (std::find (m_groups.begin(), m_groups.end(), group) - == m_groups.end()); + + auto find_by_name = [group] (const reggroup *g) + { + return streq (group->name (), g->name ()); + }; + gdb_assert (std::find_if (m_groups.begin (), m_groups.end (), find_by_name) + == m_groups.end ()); m_groups.push_back (group); }