From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1E30E3858281 for ; Sun, 14 Aug 2022 13:55:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1E30E3858281 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-136-9DGp44RwMfqriUCpKvM_Cg-1; Sun, 14 Aug 2022 09:55:07 -0400 X-MC-Unique: 9DGp44RwMfqriUCpKvM_Cg-1 Received: by mail-wm1-f69.google.com with SMTP id h127-20020a1c2185000000b003a534ec2570so1538872wmh.7 for ; Sun, 14 Aug 2022 06:55:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=cgm3OKWf2/pSVEplzkhp+TQQwJ67HrlWm4N581PYn1w=; b=HvvxGplEH+n8fyqa+jTymVzIRUbBwxdmjiXZwUHSVozl3btWCmi59hq3oOIl9H5Kkg PTYQr8nK7wvyvZ4nSdLFAHppSthIpyqTvN9a27X8T5BRnt91CC7WhtBGoew5y7FnLFqJ 0icAatZX55nluHYVkXwn68ibE6eWNZw95LgbeYn+ipiZKm/TJ5DQnGC0vOm1JoxJhugY QmByaz1c8n3954vUAqyTKg2HufQOM/wfUSryhXvdUGTLm5hb4o1rzwrzNKsR0l0gpR/i HE5CwpWLFlyeFH5sb30zt1AbbXbHalSokb+tYorcS23SGDicDwW6igThfY9B0eJeL+7z xJ8g== X-Gm-Message-State: ACgBeo3KJ4GqfLRELZWymrrcWilSjNdsneqhzPJ3DmZBLZgru18/T3XL FaxMPaD3/GfPMA+dfu2vdq/+ituKBBY37l+1/I6cCVNNz7s7uhtNawR6oTugirffZdpjXDM51B2 ei5/nq3+Q3u7TVJR+UaVZ3a+O6kEXbMu0sKoRhmLI+ZYUnr2Wa+DH12OCMoKDR6dPHwXNff0zCg == X-Received: by 2002:adf:f6c6:0:b0:221:7a12:8d69 with SMTP id y6-20020adff6c6000000b002217a128d69mr6182859wrp.346.1660485306213; Sun, 14 Aug 2022 06:55:06 -0700 (PDT) X-Google-Smtp-Source: AA6agR5UcUFbfv5s3QQJwrFDJp8E/ZdL4+490Ol+y8KtlVmWSpb2WX7TP30KQU1F2mghJKBI5whXLA== X-Received: by 2002:adf:f6c6:0:b0:221:7a12:8d69 with SMTP id y6-20020adff6c6000000b002217a128d69mr6182850wrp.346.1660485305841; Sun, 14 Aug 2022 06:55:05 -0700 (PDT) Received: from localhost (15.72.115.87.dyn.plus.net. [87.115.72.15]) by smtp.gmail.com with ESMTPSA id az15-20020adfe18f000000b0021dd08ad8d7sm4725597wrb.46.2022.08.14.06.55.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Aug 2022 06:55:05 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PUSHED] gdb/riscv: improve a comment about fcsr, fflags, and frm registers Date: Sun, 14 Aug 2022 14:55:00 +0100 Message-Id: <20220814135500.2058221-2-aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: <20220814135500.2058221-1-aburgess@redhat.com> References: <20220814135500.2058221-1-aburgess@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2022 13:55:12 -0000 There's a comment in riscv-tdep.c that explains some of the background about how we check for the fcsr, fflags, and frm registers within a riscv target description. This comment (and the functionality it describes) relates to how QEMU advertises these registers within its target description. Unfortunately, QEMU includes these three registers in both the fpu and crs target description features. To work around this GDB uses one of the register declarations, and ignores the other, this means the GDB user sees a single copy of each register, and things just work. When I originally wrote the comment I thought it didn't matter which copy of the register GDB selected, the fpu copy or the csr copy, so long as we just used one of them. The comment reflected this belief. Upon further investigation, it turns out I was wrong. GDB has to use the csr copy of the register. If GDB tries to use the register from the fpu feature then QEMU will return an error when GDB tries to read or write the register. Luckily, the code within GDB (currently) will always select the csr copy of the register, so nothing is broken, but the comment is wrong. This commit updates the comment to better describe what is actually going on. Of course, I should probably also send a patch to QEMU to fix up the target description that is sent to GDB. --- gdb/riscv-tdep.c | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c index b9a51f7ae6a..9ec430d8a10 100644 --- a/gdb/riscv-tdep.c +++ b/gdb/riscv-tdep.c @@ -3591,22 +3591,25 @@ riscv_tdesc_unknown_reg (struct gdbarch *gdbarch, tdesc_feature *feature, and CSR register sets. Some targets (QEMU) copied these target descriptions into their source - tree, and so we're currently stuck working with some targets that + tree, and so we're now stuck working with some versions of QEMU that declare the same registers twice. - There's not much we can do about this any more. Assuming the target - will direct a request for either register number to the correct - underlying hardware register then it doesn't matter which one GDB - uses, so long as we (GDB) are consistent (so that we don't end up with - invalid cache misses). - - As we always scan the FPU registers first, then the CSRs, if the - target has included the offending registers in both sets then we will - always see the FPU copies here, as the CSR versions will replace them - in the register list. - - To prevent these duplicates showing up in any of the register list, - record their register numbers here. */ + To make matters worse, if GDB tries to read or write to these + registers using the register number assigned in the FPU feature set, + then QEMU will fail to read the register, so we must use the register + number declared in the CSR feature set. + + Luckily, GDB scans the FPU feature first, and then the CSR feature, + which means that the CSR feature will be the one we end up using, the + versions of these registers in the FPU feature will appear as unknown + registers and will be passed through to this code. + + To prevent these duplicate registers showing up in any of the register + lists, and to prevent GDB every trying to access the FPU feature copies, + we spot the three problematic registers here, and record the register + number that GDB has assigned them. Then in riscv_register_name we will + return no name for the three duplicates, this hides the duplicates from + the user. */ if (strcmp (tdesc_feature_name (feature), riscv_freg_feature.name ()) == 0) { riscv_gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); -- 2.25.4