From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4trTDkaUTWIlNQAAWB0awg (envelope-from ) for ; Wed, 06 Apr 2022 09:23:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 29FD81F344; Wed, 6 Apr 2022 09:23:18 -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 91B661ED17 for ; Wed, 6 Apr 2022 09:23:17 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 41BCC3853804 for ; Wed, 6 Apr 2022 13:23:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 41BCC3853804 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1649251397; bh=myX1qmMKd75gMBYOx9WIq1tYaaeYlMaj4ssOq9XYkeI=; 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=G6vHRY+fxVp+tvbKg8W9UnQ8KYeaUf+l28aFjetTz7RI5qr+yBUMe6r6wLp+wk8oO MmKHpqh4e/XRwpdyIICBOd1OR5vLOpxUcWxVhnXSkakmG84TI7L66qiyPXaMxwF+xQ nqPM5Ki8/R53Tlt5QQeBAQDCWyKvIZsmF+6Ze0Yk= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 99E363857018 for ; Wed, 6 Apr 2022 13:22:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 99E363857018 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 236DMpQF013147 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Apr 2022 09:22:55 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 236DMpQF013147 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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id E5D261ED17; Wed, 6 Apr 2022 09:22:50 -0400 (EDT) Message-ID: Date: Wed, 6 Apr 2022 09:22:50 -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 09/16] gdb: always add the default register groups Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <5163f39f318a89b14ca41ecb4121f60ede41351b.1649246539.git.aburgess@redhat.com> In-Reply-To: <5163f39f318a89b14ca41ecb4121f60ede41351b.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 13:22:51 +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" On 2022-04-06 08:04, Andrew Burgess via Gdb-patches wrote: > There's a set of 7 default register groups. If we don't add any > gdbarch specific register groups during gdbarch initialisation, then > when we iterate over the register groups using reggroup_next and > reggroup_prev we will make use of these 7 default groups. See the use > of default_groups in gdb/reggroups.c for details on this. > > However, if the gdbarch adds its own groups during gdbarch > initialisation, then these groups will be used in preference to the > default groups. > > A problem arises though if the particular architecture makes use of > the target description mechanism. If the default target > description(s) (i.e. those internal to GDB that are used when the user > doesn't provide their own) don't mention any additional register > groups then the default register groups will be used. > > But if the target description does mention additional groups then the > default groups are not used, and instead, the groups from the target > description are used. > > The problem with this is that what usually happens is that the target > description will mention additional groups, e.g. groups for special > registers. Most architectures that use target descriptions work > around this by adding all (or most) of the default register groups in > all cases. See i386_add_reggroups, aarch64_add_reggroups, > riscv_add_reggroups, xtensa_add_reggroups, and others. > > In this patch, my suggestion is that we should just add the default > register groups for every architecture, always. This change is in > gdb/reggroups.c. > > All the remaining changes are me updating the various architectures to > not add the default groups themselves. > > So, where will this change be visible to the user? I think the > following commands will possibly change: > > * info registers / info all-registers: > > The user can provide a register group to these commands. For example, > on csky, we previously never added the 'vector' group. Now, as a > default group, this will be available, but (presumably) will not > contain any registers. I don't think this is necessarily a bad > thing, there's something to be said for having some consistent > defaults available. There are other architectures that didn't add > all 7 of the defaults, which will now have gained additional groups. > > * maint print reggroups > > This prints the set of all available groups. As a maintenance > command I'm less concerned with the output changing here. > Obviously, for the architectures that didn't previously add all the > defaults, this list just got bigger. > > * maint print register-groups > > This prints all the registers, and the groups they are in. If the > defaults were not previously being added then a register (obviously) > can't appear in one of the default groups. Now the groups are > available then registers might be in more groups than previously. > However, this is again a maintenance command, so I'm less concerned > about this changing. That sounds reasonable to me. > @@ -119,13 +110,44 @@ reggroup_add (struct gdbarch *gdbarch, struct reggroup *group) > struct reggroups *groups > = (struct reggroups *) gdbarch_data (gdbarch, reggroups_data); > > + /* The same reggroup should not be added multiple times. */ > + gdb_assert (groups != nullptr); > + for (struct reggroup_el *el = groups->first; > + el != nullptr; > + el = el->next) > + gdb_assert (group != el->group); The "for" can be on a single line. Simon