From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111194 invoked by alias); 2 Dec 2016 23:08:13 -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 111184 invoked by uid 89); 2 Dec 2016 23:08:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=qiyaoltcgmailcom, qiyaoltc@gmail.com, U*qiyaoltc, sk:qiyaolt X-HELO: mail-io0-f172.google.com Received: from mail-io0-f172.google.com (HELO mail-io0-f172.google.com) (209.85.223.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Dec 2016 23:08:02 +0000 Received: by mail-io0-f172.google.com with SMTP id m5so370422014ioe.3 for ; Fri, 02 Dec 2016 15:08:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZOjyUOXqSOFGeoQUSG/QLhTDowCCcgqm+z88wIC32cE=; b=YP04zHMfifNZN8E4PEt6S0H64mC13fIkHdojbcRiarNXOPJdaJFkU6mmX56V/sPmGK Esp7A5QuzxwrFyVDVlg2UcWgkOwIgPHaailkqGJC/hwga1ZJNdDKqObW8K9LmKE0WdD7 X40gWwPcOvcQXb5+I7JUZW9dChoYcnuZ93l+tv5JqNrDFWCC6FZHPn/qOF+VTVvuO+fR 0o3duVOAhcjH8qzoEeXufGdW+l7IEigmaL29XUkASF1X/fQ9upsy6Hx+R97E6yQPy4Hr JsPPIG4sklHsA5VRQGwIhz4xqb0Nfoa0/d+1iayxj2Puha1QfWLw/SjLt+BZjQYQwrEK SAtQ== X-Gm-Message-State: AKaTC02PJ4GMUK+uV6hkav49xf6hANIvVlecA5Is2mhkeSn5573YMnPqsu54oUbNKc/PSYfNE4JkzHwyi8aXyj/E X-Received: by 10.107.180.212 with SMTP id d203mr39295100iof.101.1480720080732; Fri, 02 Dec 2016 15:08:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.161.201 with HTTP; Fri, 2 Dec 2016 15:08:00 -0800 (PST) In-Reply-To: <20161202224952.panaxwmmrx4emord@localhost> References: <20161202214613.GA54717@beast> <20161202224952.panaxwmmrx4emord@localhost> From: Kees Cook Date: Fri, 02 Dec 2016 23:08:00 -0000 Message-ID: Subject: Re: [PATCH] Fix PTRACE_GETREGSET failure for compat inferiors on arm64 To: Yao Qi Cc: gdb-patches@sourceware.org, brian.murray@canonical.com, matthias.klose@canonical.com Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-12/txt/msg00121.txt.bz2 On Fri, Dec 2, 2016 at 2:49 PM, Yao Qi wrote: > On 16-12-02 13:46:13, Kees Cook wrote: >> When running a 32-bit ARM inferior on a 64-bit ARM host, only the hardware >> floating-point registers (NT_ARM_VFP) are available. If the inferior >> uses hard-float, do not request soft-float registers (NT_PRFPREG) and >> run the risk of failing with EINVAL. This is most noticeably exposed > > "soft-float" is not accurate. FPA is coprocessor. Both VFP and FPA is > implemented in the combination of software and hardware. I'd like to > rewrite the commit log like this, > > "When running a 32-bit ARM inferior with a 32-bit ARM GDB on 64-bit > AArch64 host, only VFP registers (NT_ARM_VFP) are available. The FPA > registers (NT_PRFPREG) is not available." That would be fine by me. I was kind of scratching my head over the naming of the types of floating-point registers. :) Whatever the case, arm64 doesn't support FPA, so an inferior using FPA couldn't run there to start with. :) >> when running "generate-core-file": >> >> (gdb) generate-core-file myprog.core >> Unable to fetch the floating point registers.: Invalid argument. >> >> ptrace(PTRACE_GETREGSET, 27642, NT_FPREGSET, 0xffcc67f0) = -1 EINVAL (Invalid argument) >> >> gdb/ChangeLog: >> >> 2016-12-02 Kees Cook > > You don't have FSF copyright assignment. Oh, hm, I thought there might be a Google-contributions-to-gdb one I was already covered under. What's the best approach for me to take to fix this? >> * gdb/arm-linux-nat.c: Skip soft-float registers when using hard-float. >> >> --- >> gdb/arm-linux-nat.c | 14 +++++++++----- >> 1 file changed, 9 insertions(+), 5 deletions(-) >> >> diff --git a/gdb/arm-linux-nat.c b/gdb/arm-linux-nat.c >> index d11bdc6..2126cd7 100644 >> --- a/gdb/arm-linux-nat.c >> +++ b/gdb/arm-linux-nat.c >> @@ -384,17 +384,19 @@ arm_linux_fetch_inferior_registers (struct target_ops *ops, >> if (-1 == regno) >> { >> fetch_regs (regcache); >> - fetch_fpregs (regcache); > > We should only call fetch_fpregs if tdep->have_fpa_registers is true. I couldn't determine how this was handled. What actually sets org.gnu.gdb.arm.fpa in tdesc? I found gdb/features/arm/arm-fpa.xml and seems to imply it's always included with arm? I wasn't able to follow, but it seemed like _having_ VFP was a indicator that FPA wasn't used. > >> if (tdep->have_wmmx_registers) >> fetch_wmmx_regs (regcache); >> if (tdep->vfp_register_count > 0) >> fetch_vfp_regs (regcache); >> + else >> + fetch_fpregs (regcache); >> } >> - else >> + else >> { >> if (regno < ARM_F0_REGNUM || regno == ARM_PS_REGNUM) >> fetch_regs (regcache); >> - else if (regno >= ARM_F0_REGNUM && regno <= ARM_FPS_REGNUM) >> + else if (tdep->vfp_register_count == 0 >> + && regno >= ARM_F0_REGNUM && regno <= ARM_FPS_REGNUM) >> fetch_fpregs (regcache); > > Do we really need this change? If FPA registers are not available, > REGNO can't fall in this range (ARM_F0_REGNUM, ARM_FPS_REGNUM). > > These two comments above also apply to store registers. It seemed like a reasonable change to make, but I see your point. -Kees -- Kees Cook Nexus Security