From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 3A88A3938C34 for ; Thu, 18 Jun 2020 09:43:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3A88A3938C34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x434.google.com with SMTP id h5so5351631wrc.7 for ; Thu, 18 Jun 2020 02:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=00O7J0xuhogHLLXgp5m7rIXO6cfEQx8uZsUmAm9MV2c=; b=AKdZ37sXfFKfqzxoiwdJ9Es7bvrSrrP+mnsAV5rLYC+RUPwF8FUxJboaX8ymAm5YO4 wQ+D1Us/CIiTpDi5Dq4cEng2NnhPOSi4/oRL9sLEr/6TtgMb3QtnaOy4P5kX3j7ETN5r Vi6Bofe/CAWYMaBsFDdgIZyoi6/VimZKz7TCX4u4F+9ROFpv86hiiX0ehyUKGHQRGCVs JUJJ1if+H6nOa0Y48DYMoV4a/T0lx9hICe5EWAZmBE+6nixQJnsVpTUsfXbK4iS/grXS OPvy3y3phsRUgM5lFB3t8NVgRP1CFBlQVMlY20egrCdjEVVYP40rwtk92/8X5jl/jSMo SLQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=00O7J0xuhogHLLXgp5m7rIXO6cfEQx8uZsUmAm9MV2c=; b=ekk2Oy3bVv1+VWTxZeTho2bnHnsITBv1M9gCTAM44mxQU1BPXbktDc5z2C8e/5AgQT sckBAGGmiXcqqjkTF+IkRd88AZOGMIEMMriOLn3tmg6zr67e2jYCVxvEnvKDsV2bBGi1 jErxqVPvKufgk1dlvNRd0OXKecSDhlEFNdncD+95zuZ0+Cm6G/QhwrrGMpqiL8exmJES Q/DZ99w9FJm0NaXu+brW+lNUVt3TsqSY489BroZSTULooNT3BQoPdLuwhtt7y2zcVw+u oh7aUMG7kiBkHpt6Q5DD+3gPSvbpxx5nwhtI+ySLefNKaH91ZGuC4TFRl2DVldY9B8Fs CVBQ== X-Gm-Message-State: AOAM532uPRIhPC4HhHAC+MsLO4mt8ze1pbhzjI2X738dyAdsrE6UZQGs MZxCbGl41Xha/CyDY1AbQcLumKg3uPQ= X-Google-Smtp-Source: ABdhPJz1gogJL1jfrRXl9Y5cGoYmhtNKmizqJyDs+WUYH62P/3dYK7hkCyQWDPR/HH8oEHZAwOvyFA== X-Received: by 2002:a5d:5489:: with SMTP id h9mr3552796wrv.125.1592473419308; Thu, 18 Jun 2020 02:43:39 -0700 (PDT) Received: from localhost (host86-128-12-16.range86-128.btcentralplus.com. [86.128.12.16]) by smtp.gmail.com with ESMTPSA id c5sm2740642wmb.24.2020.06.18.02.43.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2020 02:43:38 -0700 (PDT) Date: Thu, 18 Jun 2020 10:43:37 +0100 From: Andrew Burgess To: Sandra Loosemore Cc: "gdb-patches@sourceware.org" Subject: Re: [patch] gdb/testsuite: fixes for gdb.xml/tdesc-regs.exp Message-ID: <20200618094337.GX2737@embecosm.com> References: <71c00a14-a956-a087-8b9a-9b453194d4f2@codesourcery.com> <20200616204701.GT2737@embecosm.com> <369fc78b-2e7c-545d-fc19-53193fa93f64@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <369fc78b-2e7c-545d-fc19-53193fa93f64@codesourcery.com> X-Operating-System: Linux/5.6.15-200.fc31.x86_64 (x86_64) X-Uptime: 10:27:00 up 9 days, 23:33, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 18 Jun 2020 09:43:41 -0000 * Sandra Loosemore [2020-06-16 15:08:59 -0600]: > On 6/16/20 2:47 PM, Andrew Burgess wrote: > > > I'd be interested to know more about which targets don't place any > > registers in the 'general' group. This group is used in > > default_print_registers_info to implement 'info registers', so I'd > > like to see what this particular target has done instead. > > nios2, for one. From the original test log for nios2-linux-gnu: OK, but... Please bear with me, I don't have a nios2 tool chain to hand, but... In nios2-tdep.c, there is no call to set_gdbarch_print_registers_info, which means (from gdbarch.c) that nios2 will use default_print_registers_info. Now if we look in infcmd.c at both default_print_registers_info and registers_info, then we see that if a user says: (gdb) info registers then they will be asking which registers are in the general_reggroup. Now, nios can optionally use a remote target-description (from nios2_gdbarch_init), so, lets for now assume no target description. I see no call to set_gdbarch_register_reggroup_p for nios2, which means we are going to be using default_register_reggroup_p, which if we inspect (in reggroups.c) we'll see does place some registers into the general group. Now, does this matter? The reggroup name is never printed anywhere, we just see a set of random registers? But it is annoying that the user is not easily able to say: (gdb) info registers general and get the same output. If we look at how other targets deal with this most of them manually add at least some sub-set of the default register groups to their architectures set of register groups as part of their _gdbarch_init routine. My gut instinct here is that this is what nios2 should be doing (and maybe arm too). It does seem odd that there's no central "add-the-default-reggroups" type routine that targets can or should call. Thanks, Andrew > > maintenance print reggroups > Group Type > foo user > (gdb) FAIL: gdb.xml/tdesc-regs.exp: maintenance print reggroups > > I don't have a mainline build for ARM handy but the failure reproduces on > GDB 9 branch for arm-none-eabi. > > This is Abid's original summary of his investigation in 2018: > > There are 2 reggroups maintained in the code. One is the > default_groups which is populated in _initialize_reggroup. This group > has 'general' group. So if you do 'maint print reggroups without > loading anything in gdb, you will see 'general' group. > > The other group is stored in reggroups_data. This is populated when we > load a target description xml file. So it only has group defined in > xml file. But if has a valid group, then 'maint print reggroups' will > not use default_groups. So that command will not print 'general' group > if xml files did not have any. > > For x86, we have slightly different behavior. Its tdep code calls > i386_add_reggroups which add 'general' group to reggroups_data as > well. > > So this testcase assumes that 'general' group is always present. This > asumption is true on x86 only not in general. So I have removed it > from the match pattern. > > -Sandra