From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2B1BC433E0 for ; Thu, 25 Jun 2020 12:56:19 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AE5B12063A for ; Thu, 25 Jun 2020 12:56:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oKRAM7lM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE5B12063A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Seek1nY2itJhqqNs1vdqbjUMQeivcgNreDlrmdceLTo=; b=oKRAM7lMNcGknM667Xs4SHlDr gOEvgNwKyELCMqwWJhaF5THW3w/jnCsJlihGuUW8iYrHuxNyuEDf1oGhx+kkQPKc4iqQOFVtRZsKK pnaH7qqyaOF6hi2dWbQaae4+JftinIoPeduO04Fnr1tT8bEx/RzJLdXgdq7X28Snqwx0LMhigsZAL Q1hlrvVCCaIUI2HDMJ0eStXQ0EMpW++5RnBu4a4gT7hSHBR9VrQ7sIJDIhNId09lGiTluumy5ZAaP v+BTwmbxJgGbZ3ccSKtcvEQ1uNqtf9fvjJ08Cj39BrsFW7QraT+wbO7H5GUv+KiNsHTy/hWY4CMaC wwlNbpd3A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1joROe-0001Ya-60; Thu, 25 Jun 2020 12:54:28 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1joROa-0001Xt-Jk for linux-arm-kernel@lists.infradead.org; Thu, 25 Jun 2020 12:54:25 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1359F1FB; Thu, 25 Jun 2020 05:54:23 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.23.3]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 26E7A3F73C; Thu, 25 Jun 2020 05:54:21 -0700 (PDT) Date: Thu, 25 Jun 2020 13:54:18 +0100 From: Mark Rutland To: Will Deacon Subject: Re: [PATCH][V3] arm64: perf: Get the wrong PC value in REGS_ABI_32 mode Message-ID: <20200625125418.GC26711@C02TD0UTHF1T.local> References: <1589165527-188401-1-git-send-email-jiping.ma2@windriver.com> <20200526102611.GA1363@C02TD0UTHF1T.local> <1e57ec27-1d54-c7cd-5e5b-6c0cc47f9891@windriver.com> <20200527151928.GC59947@C02TD0UTHF1T.local> <20200528075418.GB22156@willie-the-truck> <20200618130332.GA53391@C02TD0UTHF1T.local> <20200623171909.GC4819@willie-the-truck> <20200623174456.GA5087@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200623174456.GA5087@willie-the-truck> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jiping Ma , zhe.he@windriver.com, bruce.ashfield@gmail.com, yue.tao@windriver.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, paul.gortmaker@windriver.com, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 23, 2020 at 06:44:56PM +0100, Will Deacon wrote: > On Tue, Jun 23, 2020 at 06:19:10PM +0100, Will Deacon wrote: > > So, I think we should take this patch (which puts the PC where you'd expect > > to find it for compat tasks) and then we could consider removing the current > > lr/sp fudging as a separate patch, which we could revert if it causes a > > problem. However, I'm not sure I want to open that up. > > Patch below... > > Will > > --->8 > > From 7452148b87ed8c82826474366dbe536fd960d3a7 Mon Sep 17 00:00:00 2001 > From: Jiping Ma > Date: Mon, 11 May 2020 10:52:07 +0800 > Subject: [PATCH] arm64: perf: Report the PC value in REGS_ABI_32 mode > > A 32-bit perf querying the registers of a compat task using REGS_ABI_32 > will receive zeroes from w15, when it expects to find the PC. > > Return the PC value for register dwarf register 15 when returning register > values for a compat task to perf. > > Signed-off-by: Jiping Ma > Link: https://lore.kernel.org/r/1589165527-188401-1-git-send-email-jiping.ma2@windriver.com > [will: Shuffled code and added a comment] > Signed-off-by: Will Deacon > --- > arch/arm64/kernel/perf_regs.c | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c > index 0bbac612146e..952b26a05d0f 100644 > --- a/arch/arm64/kernel/perf_regs.c > +++ b/arch/arm64/kernel/perf_regs.c > @@ -15,15 +15,25 @@ u64 perf_reg_value(struct pt_regs *regs, int idx) > return 0; > > /* > - * Compat (i.e. 32 bit) mode: > - * - PC has been set in the pt_regs struct in kernel_entry, > - * - Handle SP and LR here. > + * Our handling of compat tasks (PERF_SAMPLE_REGS_ABI_32) is weird. For > + * a 32-bit perf inspecting a 32-bit task, then it will look at the > + * first 16 registers. These correspond directly to the registers saved > + * in our pt_regs structure, with the exception of the PC, so we copy > + * that down (x15 corresponds to SP_hyp in the architecture). So far, so > + * good. The oddity arises when a 64-bit perf looks at a 32-bit task and > + * asks for registers beyond PERF_REG_ARM_MAX. In this case, we return > + * SP_usr, LR_usr and PC in the positions where the AArch64 registers > + * would normally live. The initial idea was to allow a 64-bit unwinder > + * to unwinder a 32-bit task and, although it's not clear how well that > + * works in practice, we're kind of stuck with this interface now. > */ Would you be happy with: /* * For ABI reasons, PERF_SAMPLE_REGS_ABI_32 is messy. * * 32-bit consumers of the regs expect this to look like the * native 32-bit layout with entries 0-12 being r0-r12, 13 being * the SP, 14 being the LR, and 15 being the PC. The compat SP * and LR are placed in x13 and x14 respectively upon an * exception, but we need to copy the PC into the expected slot. * Ideally the other slots would all be zeroed to match native * 32-bit, but we can't do this because of existing 64-bit * consumers. * * Existing 64-bit consumers assume that the PC, LR, and SP are * in the same positions as the PERF_SAMPLE_REGS_ABI_64 layout, * rather than interpreting PERF_SAMPLE_REGS_ABI_32 the same as * the native 32-bit PERF_SAMPLE_REGS_ABI_32. To not break these * we must copy the PC into their ABI_64 slots, and leave copies * of the SP and LR in their ABI_64 slots. * * At the time we make a sample, we don't know what the consumer * is, so we have to apply bodges both ways to avoid breaking * some binaries. */ Either way: Acked-by: Mark Rutland Mark. > if (compat_user_mode(regs)) { > if ((u32)idx == PERF_REG_ARM64_SP) > return regs->compat_sp; > if ((u32)idx == PERF_REG_ARM64_LR) > return regs->compat_lr; > + if (idx == 15) > + return regs->pc; > } > > if ((u32)idx == PERF_REG_ARM64_SP) > -- > 2.27.0.111.gc72c7da667-goog > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel