From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22132 invoked by alias); 28 Nov 2018 23:37:03 -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 21637 invoked by uid 89); 28 Nov 2018 23:37:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=sk:andrew, burgess, Burgess, sk:andrew. X-HELO: mail-ua1-f67.google.com Received: from mail-ua1-f67.google.com (HELO mail-ua1-f67.google.com) (209.85.222.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Nov 2018 23:37:01 +0000 Received: by mail-ua1-f67.google.com with SMTP id z23so24337uam.1 for ; Wed, 28 Nov 2018 15:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bl0ARssXdiLa9QOwW7237cy87acxBU5rF77KEeOwMZ8=; b=A8wrdln2uy6TiDAnG9/KAge5cvSeXrT+PbEFealiNWBIWIgWPSF5nUjk5/wLL4Fk7q TfE2/wK3bl9AaMnEOwNmQBQALCa6rH/Bvmw8mmeFohLbfWEHqpo8oj2ewE0vmuUh3P2w SnjNj2nrRr4T60qutz9Spb8gV2LycEedvMmUOmewZfwN1ZdUmYP4warAwaw2iZvk1S/l gk1XLe+FanjGocDFMKIt2CqWROuXlvxL+3nOSu9MNNusuGzqhsbl9NXX1xY0V/726gXQ 7cs/KNWsJQnb+zghPg5Cc8ZkDvO0KFHqqIxEzGwEAUoPb4Ok75bmR6sdl3mpkzQpQGSj sqPw== MIME-Version: 1.0 References: <20181128224953.22441-1-andrew.burgess@embecosm.com> In-Reply-To: <20181128224953.22441-1-andrew.burgess@embecosm.com> From: Jim Wilson Date: Wed, 28 Nov 2018 23:37:00 -0000 Message-ID: Subject: Re: [RFC] gdb/riscv: Add read_description method for riscv_linux_nat_target To: Andrew Burgess Cc: gdb-patches@sourceware.org, Palmer Dabbelt , John Baldwin Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-11/txt/msg00528.txt.bz2 On Wed, Nov 28, 2018 at 2:49 PM Andrew Burgess wrote: > Currently this will supply a suitably sized set of x-registers, and > will probe the kernel to see if the f-registers are readable. If they > are readable then we currently assume that the f-registers are the > same size as the x-registers as I don't know of a good way to probe > the f-register length. This will obviously need fixing in future. The linux kernel currently only supports 64-bit f-registers or none, so just assuming that they are 64-bits if they exist will work for now. The NT_FPREGSET ptrace call is only supported if f-registers exist, so checking for that is fine. My linux kernel patch to add f-register ptrace support adds an elf_fpreg_t type, but it is in asm/elf.h which is currently not included, and you can't use the type if you have a 4.19 or earlier kernel. The elf_gpreg_t definition is coming from sys/procfs.h which duplicates the definition in asm/elf.h, but I didn't add an elf_fpreg_t definition to sys/procfs.h, so I'm not sure what to do about that. We always have the option of using hwcap info, there are bits set in there for available architecture extensions. The hwcap support is apparently broken in some versions of the linux kernel development tree, but is hopefully correct in all supported releases. There are macros you can find in asm/hwcap.h. We would have to figure out how to get these values into gdb, since including asm/hwcap.h directly is probably not wise. Jim