From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yianBT6iTWLHNgAAWB0awg (envelope-from ) for ; Wed, 06 Apr 2022 10:22:54 -0400 Received: by simark.ca (Postfix, from userid 112) id 05ACF1F344; Wed, 6 Apr 2022 10:22:54 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 723821ED17 for ; Wed, 6 Apr 2022 10:22:53 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C83333857815 for ; Wed, 6 Apr 2022 14:22:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C83333857815 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1649254972; bh=7ZfCCnfPyw794eoNlTBteSlKkKjWpB3Zmdx9wnHf0c4=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=k+e74OH8U/rlp9TqUXkbOcCGI85v69MUhYEhWakiQLq7IlNR6pqV7s3lO74vFnfb6 jZ9pSdV7XtwMcODs5+SpPlHig8kmA0FUNIzapGzIFeFfTP74c2mp4l9K6e7QyPhI5N oy3Q5a81J9RIvEAbQsWXj63RsloeTX9jY6a/jej8= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id D6871385840C for ; Wed, 6 Apr 2022 14:22:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D6871385840C Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 236EMPCq005499 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Apr 2022 10:22:30 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 236EMPCq005499 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 31D8F1ED17; Wed, 6 Apr 2022 10:22:25 -0400 (EDT) Message-ID: <0b75bf81-3865-001e-8a8a-d6907f0ee296@polymtl.ca> Date: Wed, 6 Apr 2022 10:22:24 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCHv2 11/16] gdb: remove reggroup_next and reggroup_prev Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <3a1ef96c90157a4193af462837b63e90c0fcd6c8.1649246539.git.aburgess@redhat.com> In-Reply-To: <3a1ef96c90157a4193af462837b63e90c0fcd6c8.1649246539.git.aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 6 Apr 2022 14:22:25 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > @@ -146,62 +146,15 @@ reggroups_init (struct obstack *obstack) > return groups; > } > > -/* A register group iterator. */ > - > -struct reggroup * > -reggroup_next (struct gdbarch *gdbarch, const struct reggroup *last) > -{ > - /* Don't allow this function to be called during architecture > - creation. If there are no groups, use the default groups list. */ > - struct reggroups *groups > - = (struct reggroups *) gdbarch_data (gdbarch, reggroups_data); > - gdb_assert (groups != nullptr); > - gdb_assert (groups->size () > 0); > - > - /* Return the first/next reggroup. */ > - if (last == nullptr) > - return groups->groups ().front (); > - for (int i = 0; i < groups->size (); ++i) > - { > - if (groups->groups ()[i] == last) > - { > - if (i + 1 < groups->size ()) > - return groups->groups ()[i + 1]; > - else > - return nullptr; > - } > - } > - > - return nullptr; > -} > - > /* See reggroups.h. */ > - > -struct reggroup * > -reggroup_prev (struct gdbarch *gdbarch, const struct reggroup *curr) > +const std::vector > +gdbarch_reggroups (struct gdbarch *gdbarch) Should this return a reference to the existing vector, so it doesn't make a copy of the vector each time? > diff --git a/gdb/tui/tui-regs.c b/gdb/tui/tui-regs.c > index b968947fa1c..acffc75238a 100644 > --- a/gdb/tui/tui-regs.c > +++ b/gdb/tui/tui-regs.c > @@ -514,34 +514,48 @@ tui_data_item_window::rerender (WINDOW *handle, int field_width) > (void) wstandend (handle); > } > > -/* Helper for "tui reg next", wraps a call to REGGROUP_NEXT, but adds wrap > - around behaviour. Will never return nullptr. If CURRENT_GROUP is > - nullptr (e.g. if the tui register window has only just been displayed > - and has no current group selected), then the first register group will > - be returned. */ > +/* Helper for "tui reg next", returns the next register group after > + CURRENT_GROUP in the register group list for GDBARCH, with wrap around > + behaviour. > + > + If CURRENT_GROUP is nullptr (e.g. if the tui register window has only > + just been displayed and has no current group selected) or the currently > + selected register group can't be found (e.g. if the architecture has > + changed since the register window was last updated), then the last > + register group will be returned. */ last or next? This is for tui_reg_next. > > static const reggroup * > tui_reg_next (const reggroup *current_group, struct gdbarch *gdbarch) > { > - const reggroup *group = reggroup_next (gdbarch, current_group); > - if (group == NULL) > - group = reggroup_next (gdbarch, NULL); > - return group; > + const std::vector &groups = gdbarch_reggroups (gdbarch); > + auto it = std::find (groups.begin (), groups.end (), current_group); > + if (it != groups.end ()) > + it++; > + if (it == groups.end ()) > + return groups.front (); > + return *it; My only thought for the conversion to vector is that using an intrusive_list would be a nice lightweight solution for those next/prev cases. You wouldn't have to iterate the vector to find the current reggroup, to find the one after it. However, it would probably not handle the "if the architecture has changed since the register window was last updated case", where you want to check if the current group is part of gdbarch's reggroups. When the current architecture changes though, I think it should trigger an update of the register window to show that new architecture's registers so... maybe we don't need this check?