Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp3209031rwd; Mon, 22 May 2023 10:05:44 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6bxSVdEo9d83LRF1wFPiI/ikIXv0pvjcVX+vob/Vs4h5FpQwi0feV1Wa84FBItu9Jr8KBm X-Received: by 2002:a17:90a:5204:b0:253:24ce:cbd1 with SMTP id v4-20020a17090a520400b0025324cecbd1mr9960418pjh.6.1684775144465; Mon, 22 May 2023 10:05:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684775144; cv=none; d=google.com; s=arc-20160816; b=Sx02damYg9wz4Yh43yfz3R0cuZPDYy/SJuX98mLJajmf+YF2LurlXQeOjlhc5EDyIk dqJFs4PloSM5W6LhF+EEe2WfRbSJeCQm+vtJbkd0DoCIdbaD2R83zu8Ny3Bpo7hxrMHV 8wFCkpUHpARWW+a4cpLPng8K381Aoinf+qhFiJ02GzgJQQpXrdEekieA590su0u25CH4 EKpvXl5iUaS56r16Gl0tjboB87DvarPq4Gkey0GrKuQ8GiUu+sgOMHluIUEcYy5Tif27 OjNpjwSxbZ5PEswxJUbzDr34UoR4qukmNM2C6Oflfgh9es8L1l0Ec11sOUXHpR3Q/jY/ cQsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=dyRxgDMh7UD/2IonWdJj/2leU4ubMcYdubIBm8F0No4=; b=0gmKxHiUOsiGR3+aCHTCV1vh4VcBILOr1I0mO99b0IuYJMi/sFSCLqLME0BYxLsdfF iD2kACFXh5nfzbcfjU2rHTrQbNoTu82k8NsmQNc1rLNnQ98WS6UyHvR70CK0Bt6xu3Oy //9lWLwrfM03CQ71guYb7jzmNI/nLzcC/cK/o+QtCZ154sNoxoqnXrhlLCWC6yiFkZsL VurjWzQDM7L2CZOPcAJq4LfHv97ll8DcM8w1d+Fx49hRNfhs5RhUFQNm85h/j/nU9e+F IPNCZMYIrvap0VAgXcM78V6kcLCMG7MdK5ZYV+HDJD4TcKUJ73m6oKy73CqZGmfySM97 C0kA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ct21-20020a17090af59500b00246ff7fbff8si4722218pjb.11.2023.05.22.10.05.31; Mon, 22 May 2023 10:05:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232845AbjEVQel (ORCPT + 99 others); Mon, 22 May 2023 12:34:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231721AbjEVQek (ORCPT ); Mon, 22 May 2023 12:34:40 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 75EF1CF; Mon, 22 May 2023 09:34:37 -0700 (PDT) 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 17A0811FB; Mon, 22 May 2023 09:35:22 -0700 (PDT) Received: from [10.57.84.18] (unknown [10.57.84.18]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B1BCF3F762; Mon, 22 May 2023 09:34:33 -0700 (PDT) Message-ID: Date: Mon, 22 May 2023 17:34:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v1 2/5] perf parse-regs: Introduce functions arch__reg_{ip|sp}() Content-Language: en-US To: Leo Yan Cc: Arnaldo Carvalho de Melo , John Garry , Will Deacon , Mike Leach , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Guo Ren , Paul Walmsley , Palmer Dabbelt , Albert Ou , Eric Lin , Kan Liang , Qi Liu , Sandipan Das , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-csky@vger.kernel.org, linux-riscv@lists.infradead.org References: <20230520025537.1811986-1-leo.yan@linaro.org> <20230520025537.1811986-3-leo.yan@linaro.org> <839836e8-9600-9249-dcdb-e29519335141@arm.com> <20230522120729.GB1826292@leoy-yangtze.lan> From: James Clark In-Reply-To: <20230522120729.GB1826292@leoy-yangtze.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/05/2023 13:07, Leo Yan wrote: > On Mon, May 22, 2023 at 09:57:25AM +0100, James Clark wrote: >> >> >> On 20/05/2023 03:55, Leo Yan wrote: >>> Ideally, we want util/perf_regs.c to be general enough and doesn't bind >>> with specific architecture. >>> >>> But since util/perf_regs.c uses the macros PERF_REG_IP and PERF_REG_SP >>> which are defined by architecture, thus util/perf_regs.c is dependent on >>> architecture header (see util/perf_regs.h includes "", here >>> perf_regs.h is architecture specific header). >>> >>> As a step to generalize util/perf_regs.c, this commit introduces weak >>> functions arch__reg_ip() and arch__reg_sp() and every architecture can >>> define their own functions; thus, util/perf_regs.c doesn't need to use >>> PERF_REG_IP and PERF_REG_SP anymore. >>> >>> This is a preparation to get rid of architecture specific header from >>> util/perf_regs.h. >>> >>> Signed-off-by: Leo Yan >>> --- >> [...] >>> >>> -#define DWARF_MINIMAL_REGS ((1ULL << PERF_REG_IP) | (1ULL << PERF_REG_SP)) >>> +#define DWARF_MINIMAL_REGS ((1ULL << arch__reg_ip()) | (1ULL << arch__reg_sp())) >>> >>> const char *perf_reg_name(int id, const char *arch); >>> int perf_reg_value(u64 *valp, struct regs_dump *regs, int id); >>> diff --git a/tools/perf/util/unwind-libdw.c b/tools/perf/util/unwind-libdw.c >>> index bdccfc511b7e..f308f2ea512b 100644 >>> --- a/tools/perf/util/unwind-libdw.c >>> +++ b/tools/perf/util/unwind-libdw.c >>> @@ -252,7 +252,7 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg, >>> if (!ui->dwfl) >>> goto out; >>> >>> - err = perf_reg_value(&ip, &data->user_regs, PERF_REG_IP); >>> + err = perf_reg_value(&ip, &data->user_regs, arch__reg_ip()); >> >> Shouldn't it be more like this, because the weak symbols are a compile >> time thing and it's supposed to support cross arch unwinding at runtime >> (assuming something containing the arch from the file is passed down, >> like we did with perf_reg_name()): >> >> char *arch = perf_env__arch(evsel__env(evsel)); >> err = perf_reg_value(&ip, &data->user_regs, arch__reg_ip(arch)); > > Thanks for pointing out, James. > > Agreed that we need to return the IP and SP register based on the > arch. I will look into more details and spin for a new patch set for > this. > You might be able to skip the extra work for now though, seeing as your change is no worse than it was before and it fixes the duplicate declaration issue. >> Now I'm wondering how cross unwinding ever worked because I see >> libunwind also has something hard coded too: >> >> #define LIBUNWIND__ARCH_REG_SP PERF_REG_SP > > Yeah, I also used arch__reg_sp() to replace PERF_REG_SP; but as you > suggestion, we should fix this with passing 'arch' parameter for > getting SP register based on arch. > > Another important thing is to find a good test for cross unwinding. > Maybe I can use tools/perf/tests/shell/record.sh, function > test_register_capture() for testing registers, if you have any other > suggesion, please let me know. The only way I can think is to have pre-recorded perf.data files in the repo, but they'd also need the binary from the recording too. I think this is probably not a very good idea because it's going to make the repo huge if we keep changing them (which we will). Some kind of third party perf test suite hosted somewhere might work but I don't think this exists. > > Thanks, > Leo