Message ID | 20240214113947.240957-1-leo.yan@linux.dev |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-65148-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:bc8a:b0:106:860b:bbdd with SMTP id dn10csp1148803dyb; Wed, 14 Feb 2024 03:40:31 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUsRfYUJJPb6beA3GgHRSOBwet5daYBPVEXhR4CalmA54FM/1pLW1QDpJxaaVpurWfs9Ciu7zx/JKvKrGnEufnXPimlQw== X-Google-Smtp-Source: AGHT+IF1gJY2RVWwefJgRNGjRRc+ZLSifOUxWGAl1NqmvHhHVe/Ly8+ORmYoT8fMNdnphzQLLe/b X-Received: by 2002:a17:906:374a:b0:a3d:2637:b713 with SMTP id e10-20020a170906374a00b00a3d2637b713mr1834141ejc.54.1707910831466; Wed, 14 Feb 2024 03:40:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707910831; cv=pass; d=google.com; s=arc-20160816; b=G8sTPzsO53JuXDp+B6Zq3GW88B/cx9vrc5XG5EwVcRFbhZp1R4e2+qsk7CvVq3Wss8 ur7l4mj3KoZfF9zVsue5Nc2bzoErE8WIpeHuRf7WYIHVQYx2h1wJ60scvvrdSENTEb/5 ddHVi47ub1He4L7MgAMA/+bjnvKMj7EYbGzfCsNcjD5Vx4OTQRkDIKfkLWZzSkWpGCO5 FUk4w09TzTm5RxviDDsJ2quKIF7yT/fasIDYC+inBx7lkeAazTaU+9OgNXZvdcnhB0PJ damTG5EcIbx1FIhnn3pyV98EFz9spYgmtxnTnXQxZWivIBHm+wSB3CAch3wizepfmOk2 Ii7A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=uT81D9JadSG4shnyPAzeCNq5QuDdA42vAVAwALPxupk=; fh=xMHWZJB3DJYbd3vQuGxq+ibloUBM7trIzaRNJ5WFPwg=; b=MoG0LWYgE+jPfBffnjvaIscxOO8YDGEaUwqDWnUpZqcRGlWwB4HTUoyaMWe9m0NPAG Y6lJ8X8jpqJnyLyUrWlAk2gBNQkrxjO3PheNsnQlPtQHKccVlCoXndQR/9/u2x/IEds9 kr3HYbH8st45j2x1q3Nlg6X+GdzayjNtXakvNbeRlwKsIgswlS0A7sul+2t/m1uNe8t9 /7RCAO/mxUAtEEbkPYp1FlgkOqUv9FR6ThCTPt6zt3NezfkRmZMBfdZYDhjZFEt3WCEr lZbQMbrmBJgvsnq3H1RER+g9+adodBWGtdv2hlZsWlIV1g8akmC+MEG6f5nlMQGPZY+P I2Gg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=i6yVSl6u; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-65148-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-65148-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev X-Forwarded-Encrypted: i=2; AJvYcCWpfnsB0IOWKQ988TvaAbZNdpTUr6j4W1YmX5D7EI0Q8Hgp5Y3nRU/fw9RXhL4RBo2+VuO5M2mdVbnm6+cGMLk2/a7gsQ== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id f7-20020a1709062c4700b00a3d11b7a7d5si1281656ejh.508.2024.02.14.03.40.31 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Feb 2024 03:40:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-65148-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=i6yVSl6u; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-65148-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-65148-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 1A3B81F21868 for <ouuuleilei@gmail.com>; Wed, 14 Feb 2024 11:40:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0F8671AAD7; Wed, 14 Feb 2024 11:40:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="i6yVSl6u" Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0047312B61 for <linux-kernel@vger.kernel.org>; Wed, 14 Feb 2024 11:40:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707910815; cv=none; b=ZYQquVJsQeBt3Nj5lzSDhojMaL660JVm8t574nSxlLsQIvqL7asBLR3oObFvoT1zaGdAJLqHYJJoRM7z96hCGjQvcjDu6C2wmRhTzHkcxWt4ZHXoDYq4H6C4+8CB+Wp3Q4xniar+cbXR2Kse9vv1+xO4q5SMWC8630Mf/8URW9Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707910815; c=relaxed/simple; bh=WNSlR33tBViXu08xbrYk0ySUbQI6bmCyn/fNCHmqg6U=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=ObmKbyJuhOCBX+ME/aj7TIFfcMsDVFTr//tGMwzbOgoVP1d3q46S4vEWSHYNRzIv1oWMv3EiOQMBNGgrlWVGtPTFoyXr6+mjeIMw3WkLC+PJ5xSBlDA7B7VvQaA4tZgApej4usvlgIKgrcrKAzboFYCrlUGqTGgVipWP1Aecbng= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=i6yVSl6u; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707910810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=uT81D9JadSG4shnyPAzeCNq5QuDdA42vAVAwALPxupk=; b=i6yVSl6uTdkrx6HNLprqf5oHzRLgtC5JZQkJuQR6agOvHCg/AMST2eLGx1vFU3A00TNMDc W6HIk/+HvpVx4AhZasgIvsCQXJOr/PttA4KuQJETrVo5d3VvyVx4r36xtpuK4BnKIJ1efl CE0D7myb/TkQwGbDq2rSHjzxZkTlhhI= From: Leo Yan <leo.yan@linux.dev> To: Arnaldo Carvalho de Melo <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, John Garry <john.g.garry@oracle.com>, Will Deacon <will@kernel.org>, James Clark <james.clark@arm.com>, Mike Leach <mike.leach@linaro.org>, Guo Ren <guoren@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Huacai Chen <chenhuacai@kernel.org>, Ming Wang <wangming01@loongson.cn>, Kan Liang <kan.liang@linux.intel.com>, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, linux-csky@vger.kernel.org, linux-riscv@lists.infradead.org Cc: Leo Yan <leo.yan@linux.dev> Subject: [PATCH v1 0/4] perf parse-regs: Cleanup config and building Date: Wed, 14 Feb 2024 19:39:43 +0800 Message-Id: <20240214113947.240957-1-leo.yan@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790874308012149305 X-GMAIL-MSGID: 1790874308012149305 |
Series |
perf parse-regs: Cleanup config and building
|
|
Message
Leo Yan
Feb. 14, 2024, 11:39 a.m. UTC
Currently, the perf building enables register parsing based on the target architecture has supported register feature. Furthermore, the perf building system needs to maintain a variable 'NO_PERF_REGS' and defines macro 'HAVE_PERF_REGS_SUPPORT' for statically compiling the tool. As a result, the perf has no flexibilty for parsing register if an architecture doesn't support it. And the source files use the macro 'HAVE_PERF_REGS_SUPPORT' to switch on and off the register parsing related code, which is not a good practice. This series is to remove the static building for register parsing. In theory, we should can dynamically detect if an arch has support this feature and functions can return errors when the feature is not supported. The first patch is to remove unused build configuration CONFIG_PERF_REGS. The second patch is to build perf register functions, without using the macro 'HAVE_PERF_REGS_SUPPORT' to statically turn on or off code. The third patch is to introduce a weak function arch__sample_reg_masks(), this function can allow the target arch to return its sample register list. With this change, we can totally remove the macro 'HAVE_PERF_REGS_SUPPORT' in the source file. The forth patch is to clean up the Makefile for removing relevant configuration and macro definition, as they are not useful anymore. I tested this patch set on Arm64 and x86 for building and did a cross register parsing ('perf record' on Arm64 and 'perf report' on x86). Leo Yan (4): perf build: Remove unused CONFIG_PERF_REGS perf parse-regs: Always build perf register functions perf parse-regs: Introduce a weak function arch__sample_reg_masks() perf build: Cleanup perf register configuration tools/perf/Makefile.config | 25 -------------- tools/perf/arch/arm/util/perf_regs.c | 7 +++- tools/perf/arch/arm64/util/machine.c | 2 ++ tools/perf/arch/arm64/util/perf_regs.c | 7 +++- tools/perf/arch/csky/util/perf_regs.c | 7 +++- tools/perf/arch/loongarch/util/perf_regs.c | 7 +++- tools/perf/arch/mips/util/perf_regs.c | 7 +++- tools/perf/arch/powerpc/util/perf_regs.c | 7 +++- tools/perf/arch/riscv/util/perf_regs.c | 7 +++- tools/perf/arch/s390/util/perf_regs.c | 7 +++- tools/perf/arch/x86/util/perf_regs.c | 7 +++- tools/perf/util/parse-regs-options.c | 8 ++--- .../util/perf-regs-arch/perf_regs_aarch64.c | 4 --- .../perf/util/perf-regs-arch/perf_regs_arm.c | 4 --- .../perf/util/perf-regs-arch/perf_regs_csky.c | 4 --- .../util/perf-regs-arch/perf_regs_loongarch.c | 4 --- .../perf/util/perf-regs-arch/perf_regs_mips.c | 4 --- .../util/perf-regs-arch/perf_regs_powerpc.c | 4 --- .../util/perf-regs-arch/perf_regs_riscv.c | 4 --- .../perf/util/perf-regs-arch/perf_regs_s390.c | 4 --- .../perf/util/perf-regs-arch/perf_regs_x86.c | 4 --- tools/perf/util/perf_regs.c | 11 ++++-- tools/perf/util/perf_regs.h | 34 +------------------ 23 files changed, 67 insertions(+), 112 deletions(-)
Comments
On Wed, Feb 14, 2024 at 3:40 AM Leo Yan <leo.yan@linux.dev> wrote: > > Currently, the perf building enables register parsing based on the > target architecture has supported register feature. > > Furthermore, the perf building system needs to maintain a variable > 'NO_PERF_REGS' and defines macro 'HAVE_PERF_REGS_SUPPORT' for statically > compiling the tool. > > As a result, the perf has no flexibilty for parsing register if an > architecture doesn't support it. And the source files use the macro > 'HAVE_PERF_REGS_SUPPORT' to switch on and off the register parsing > related code, which is not a good practice. > > This series is to remove the static building for register parsing. In > theory, we should can dynamically detect if an arch has support this > feature and functions can return errors when the feature is not > supported. > > The first patch is to remove unused build configuration > CONFIG_PERF_REGS. > > The second patch is to build perf register functions, without using the > macro 'HAVE_PERF_REGS_SUPPORT' to statically turn on or off code. > > The third patch is to introduce a weak function arch__sample_reg_masks(), > this function can allow the target arch to return its sample register > list. With this change, we can totally remove the macro > 'HAVE_PERF_REGS_SUPPORT' in the source file. > > The forth patch is to clean up the Makefile for removing relevant > configuration and macro definition, as they are not useful anymore. > > I tested this patch set on Arm64 and x86 for building and did a cross > register parsing ('perf record' on Arm64 and 'perf report' on x86). > > > Leo Yan (4): > perf build: Remove unused CONFIG_PERF_REGS > perf parse-regs: Always build perf register functions > perf parse-regs: Introduce a weak function arch__sample_reg_masks() > perf build: Cleanup perf register configuration Thanks Leo, this is great cleanup! Series: Reviewed-by: Ian Rogers <irogers@google.com> Ian > tools/perf/Makefile.config | 25 -------------- > tools/perf/arch/arm/util/perf_regs.c | 7 +++- > tools/perf/arch/arm64/util/machine.c | 2 ++ > tools/perf/arch/arm64/util/perf_regs.c | 7 +++- > tools/perf/arch/csky/util/perf_regs.c | 7 +++- > tools/perf/arch/loongarch/util/perf_regs.c | 7 +++- > tools/perf/arch/mips/util/perf_regs.c | 7 +++- > tools/perf/arch/powerpc/util/perf_regs.c | 7 +++- > tools/perf/arch/riscv/util/perf_regs.c | 7 +++- > tools/perf/arch/s390/util/perf_regs.c | 7 +++- > tools/perf/arch/x86/util/perf_regs.c | 7 +++- > tools/perf/util/parse-regs-options.c | 8 ++--- > .../util/perf-regs-arch/perf_regs_aarch64.c | 4 --- > .../perf/util/perf-regs-arch/perf_regs_arm.c | 4 --- > .../perf/util/perf-regs-arch/perf_regs_csky.c | 4 --- > .../util/perf-regs-arch/perf_regs_loongarch.c | 4 --- > .../perf/util/perf-regs-arch/perf_regs_mips.c | 4 --- > .../util/perf-regs-arch/perf_regs_powerpc.c | 4 --- > .../util/perf-regs-arch/perf_regs_riscv.c | 4 --- > .../perf/util/perf-regs-arch/perf_regs_s390.c | 4 --- > .../perf/util/perf-regs-arch/perf_regs_x86.c | 4 --- > tools/perf/util/perf_regs.c | 11 ++++-- > tools/perf/util/perf_regs.h | 34 +------------------ > 23 files changed, 67 insertions(+), 112 deletions(-) > > -- > 2.34.1 >
On Wed, Feb 14, 2024 at 02:42:55PM -0800, Ian Rogers wrote: [...] > Thanks Leo, this is great cleanup! Series: > Reviewed-by: Ian Rogers <irogers@google.com> Thanks a lot for reviewing, Ian! Leo
On Wed, 14 Feb 2024 19:39:43 +0800, Leo Yan wrote: > Currently, the perf building enables register parsing based on the > target architecture has supported register feature. > > Furthermore, the perf building system needs to maintain a variable > 'NO_PERF_REGS' and defines macro 'HAVE_PERF_REGS_SUPPORT' for statically > compiling the tool. > > [...] Applied to perf-tools-next, thanks! Best regards,