From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67790 invoked by alias); 2 Dec 2016 22:49:59 -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 67759 invoked by uid 89); 2 Dec 2016 22:49:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=HTo:D*chromium.org X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Dec 2016 22:49:58 +0000 Received: by mail-wm0-f68.google.com with SMTP id u144so4766340wmu.0 for ; Fri, 02 Dec 2016 14:49:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/JDkmfSucXdvfbv4Zfq4yjzgFDthZskkX4nxHiRP56E=; b=M5n+YgJSDZjCQdyzTh+/kf6q05uvX4pT02dyQSnA1UabBJGmSO+eiYakRbv6fVVRqq zQs55J08a5pDPU2NXJpe9KeRDAEoz6E/N71g2Rro/vPjfhYGE4lreLIaVIQFZ64vGxZC DNbeK+kZQfie7UewsxPLUMhlY0k2lQTPJsnwRlAV5me6Eyi1DVZ75D1ZoutPuOTD3lMM p8MuXtofe1qMnniHz0nH4kqeqHfL8j9RgejrOl34L7emZCj1Og9EKWYe8Q5eTmc4wng5 abhamhLL/Vz5GFg/VCPX7r/QhINoAW7h+IX7GGT5FgEw3BnPa9JkOHLxoGdgN/ChWajp VKVw== X-Gm-Message-State: AKaTC01xjnjqdWyvoQqatkxWpAoMFMFUs/kQvzjczGrDx/LE4db47T370PfaWhDhk+n1GQ== X-Received: by 10.28.138.137 with SMTP id m131mr4799367wmd.118.1480718995849; Fri, 02 Dec 2016 14:49:55 -0800 (PST) Received: from localhost ([2a02:c7d:8e80:c00:edc6:e79a:327b:7624]) by smtp.gmail.com with ESMTPSA id e188sm5351055wma.21.2016.12.02.14.49.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Dec 2016 14:49:55 -0800 (PST) Date: Fri, 02 Dec 2016 22:49:00 -0000 From: Yao Qi To: Kees Cook Cc: gdb-patches@sourceware.org, brian.murray@canonical.com, matthias.klose@canonical.com Subject: Re: [PATCH] Fix PTRACE_GETREGSET failure for compat inferiors on arm64 Message-ID: <20161202224952.panaxwmmrx4emord@localhost> References: <20161202214613.GA54717@beast> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161202214613.GA54717@beast> User-Agent: NeoMutt/20161104 (1.7.1) X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00119.txt.bz2 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." > 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. > > * 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. > 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. -- Yao