From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84914 invoked by alias); 22 May 2019 11:37:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 84906 invoked by uid 89); 22 May 2019 11:37:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-13.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wm1-f68.google.com Received: from mail-wm1-f68.google.com (HELO mail-wm1-f68.google.com) (209.85.128.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 May 2019 11:37:52 +0000 Received: by mail-wm1-f68.google.com with SMTP id 7so1847258wmo.2 for ; Wed, 22 May 2019 04:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=from:to:cc:subject:date:message-id; bh=DWEArzG3Cl78M3za3lKaSr9pPI0QhV4yJ8L1jqwjh0k=; b=gE/amNBmlft5nR02GsNQ9ZWf8DDhesnnoirWzOFf7hB9GMOrDAqPEDL1/ertR6yCFJ eeJYtcK1QG/VlCgQuq/k8APoTYqMb0pcJ0QBcWpFlCmUXUwjwYgoM3Zh2j0dCvxA2Tcp BuVr1TD1vZJV773jkHM3S6KJ4AU8zesXRSbrhdq5Wm7VFF1rjPvbO3jtAygOLkdGTm49 JIROrG7Y0Pq0hAuE83JcX4uTZDM3Eb1m6EO4zM1iLtB8lX5aG4dsdA4nhzxNFkBsGqdj f0D7XCEedWy1eHOmp8vz9sZSB0xHGi15rZ6+XvnejUHGGxS+sMbTnV3Wz1e1VKZaJcdA TSTw== Return-Path: Received: from sidgwick.lym.embecosm-corp.com (cust64-dsl91-135-5.idnet.net. [91.135.5.64]) by smtp.gmail.com with ESMTPSA id 6sm30602920wrd.51.2019.05.22.04.37.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 04:37:49 -0700 (PDT) From: Simon Cook To: gdb-patches@sourceware.org Cc: simon.cook@embecosm.com Subject: [PATCH] gdb/riscv: Improve flen length determiniation Date: Wed, 22 May 2019 11:37:00 -0000 Message-Id: <20190522113745.26750-1-simon.cook@embecosm.com> X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00487.txt.bz2 This solves an assertion failure when a remote provides a target description which only refers to floating point registers by their hardware name (e.g. f0), rather than their ABI name (e.g. ft0). GDB assumed that should the floating point register feature be presented, it would contain a register called ft0. The floating point length is now instead determined by searching for the same register, but looking for any of its aliases. gdb/ChangeLog: * riscv-tdep.c (riscv_gdbarch_init): Support determining flen from target descriptions using exclusively floating point register name aliases. --- gdb/ChangeLog | 6 ++++++ gdb/riscv-tdep.c | 17 ++++++++++++++++- 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c index 4fe07ef437..072c8e3720 100644 --- a/gdb/riscv-tdep.c +++ b/gdb/riscv-tdep.c @@ -3094,7 +3094,22 @@ riscv_gdbarch_init (struct gdbarch_info info, valid_p &= riscv_check_tdesc_feature (tdesc_data, feature_fpu, &riscv_freg_feature); - int bitsize = tdesc_register_bitsize (feature_fpu, "ft0"); + /* Search for the first floating point register (by any alias), to + determine the bitsize. */ + int bitsize = -1; + const auto &fp0 = riscv_freg_feature.registers[0]; + + for (const char *name : fp0.names) + { + if (tdesc_unnumbered_register (feature_fpu, name)) + { + bitsize = tdesc_register_bitsize (feature_fpu, name); + break; + } + } + + gdb_assert (bitsize != -1); + features.flen = (bitsize / 8); if (riscv_debug_gdbarch) -- 2.17.1