From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 741 invoked by alias); 30 Jan 2020 22:56:44 -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 724 invoked by uid 89); 30 Jan 2020 22:56:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=probe, sk:ptrace_, sk:PTRACE_, our X-HELO: mail-ua1-f65.google.com Received: from mail-ua1-f65.google.com (HELO mail-ua1-f65.google.com) (209.85.222.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Jan 2020 22:56:41 +0000 Received: by mail-ua1-f65.google.com with SMTP id y23so1860413ual.2 for ; Thu, 30 Jan 2020 14:56:41 -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=zu2PpFx6r9tWSpdfkRJRUy8hxxaym2ayDdIPV/Eof8k=; b=jhGFIrOvV/70eFt16k3XZeh+w9QHz/LB3wynz/RAQeW+QZO7G/CDekO2IBVO7ys9oH Xho4tA3iPyquaVkwYcjTiSFHTaYowKyluOdhKVeznkpG09jJO4M9Gm1YJvYDV1FKNtlq QqiYKX29ISzvscXjbIvGnCbzyIrG3Zh7nVYrJJZ4jA7oz3Jja+MrF4Bxbfvwr07h/evz U11pSu7hb5EMPlMjTMhWb9mkylPfbszyF08pIHgvHOt4VoWhpQBtbLhUJvXQWx6vnozP JJf85qRtTOrC9bQrbBp8RSVn3HJRxX6x9R89hPfuofd5YaWupWgk4wFfD3HQ0a3gEGcj 8SYA== MIME-Version: 1.0 References: In-Reply-To: From: Jim Wilson Date: Thu, 30 Jan 2020 23:19:00 -0000 Message-ID: Subject: Re: [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically To: "Maciej W. Rozycki" Cc: "gdb-patches@sourceware.org" , Andrew Burgess , Palmer Dabbelt , Tom Tromey , "guoren@kernel.org" , "lifang_xia@c-sky.com" , "yunhai_shang@c-sky.com" , "jiangshuai_li@c-sky.com" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00979.txt.bz2 On Wed, Jan 29, 2020 at 10:13 AM Maciej W. Rozycki wrote: > We can do better however and not rely on any particular value of FLEN > and probe for it dynamically, by observing that the PTRACE_GETREGSET > ptrace(2) call will only accept an exact regset size, and that will > reflect FLEN. I forgot to mention this before, but our long term plans are to pass info via the auxiliary vector from the kernel to the application, and then in theory gdb should be able to get architecture info from there. This may require support that hasn't been written yet, and we may still need the fp probing for older systems that don't have all of the support needed to make aux vec work. Just with a quick check on my 4.15 kernel, I see hifiveu017:1030$ ./a.out AT_HWCAP = 0x1105 that is 'a', 'c', 'i', and 'm', each represented as 1<<(x-'a'). The 'f' and 'd' info is missing for some reason. Maybe it hadn't been implemented yet in this kernel version. Jim