From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118024 invoked by alias); 4 Dec 2016 19:30:50 -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 118005 invoked by uid 89); 4 Dec 2016 19:30:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Nexus, Hx-languages-length:1381, nexus, qiyaoltc@gmail.com 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; Sun, 04 Dec 2016 19:30:39 +0000 Received: by mail-io0-f172.google.com with SMTP id m5so426520159ioe.3 for ; Sun, 04 Dec 2016 11:30:38 -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=oF79sy5dxsh5VFR+drEp4CgWa362OWCeWue5J10WQYE=; b=Tw3tpT4uozMClbOOnRqzJr1hgEjE3Ts06OSWsJLMlBzyGuXzt4KZS+RpeMiaUBKHIq uTxYlmOmrTrr8W/VVgxTgd49jIipYobB+cKdW1ok1QHalBez5L+ChEnvPXn2epYmzQHe ow33QVadjySKlH9PSnXaUHaZR26nFq27qNEiP4+ul9NYORc4AfvLXKTGm8l/0YJ433BT zoVKBw9j/D9jQ1VwQ0gx/tntfKLqurWNeo+P2OpLT2v9J1WK7zc38cERXkETQMIEwJjO I0ubY986vZMgy1LCzVQ5gyzPibAz3D+v4lw9LLOshtnSPScxYNSULZm+KBIm1yu3Is1U I28Q== X-Gm-Message-State: AKaTC00UjdDYAO4wro4KUgW/vVUExJbc4yT3EnKQHp3z1KmpdsYKtUwdObFpuNTd6SLSGobgNydYV3s7jHelffQe X-Received: by 10.107.172.134 with SMTP id v128mr48502197ioe.49.1480879837363; Sun, 04 Dec 2016 11:30:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.161.201 with HTTP; Sun, 4 Dec 2016 11:30:36 -0800 (PST) In-Reply-To: References: <20161202214613.GA54717@beast> <20161202224952.panaxwmmrx4emord@localhost> From: Kees Cook Date: Sun, 04 Dec 2016 19:30: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 , Matthias Klose Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-12/txt/msg00127.txt.bz2 On Sun, Dec 4, 2016 at 3:11 AM, Yao Qi wrote: > On Fri, Dec 2, 2016 at 11:08 PM, Kees Cook wrote: >>>> 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. >> > > What is I meant is that instead of calling fetch_fpregs unconditionally, > we call fetch_fpregs if tdep->have_fpa_registers is true, like this, > > if (tdep->have_fpa_registers) > fetch_fpregs (regcache); > > IOW, we only fetch FPA registers if we know FPA registers are available, > as described in target description. Right, I was asking how the target description is built. I couldn't determine where FPA was detected. -Kees -- Kees Cook Nexus Security