From: Adrian Hunter <adrian.hunter@intel.com>
To: Ian Rogers <irogers@google.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
"John Garry" <john.g.garry@oracle.com>,
"Will Deacon" <will@kernel.org>,
"James Clark" <james.clark@arm.com>,
"Mike Leach" <mike.leach@linaro.org>,
"Leo Yan" <leo.yan@linaro.org>,
"Mathieu Poirier" <mathieu.poirier@linaro.org>,
"Suzuki K Poulose" <suzuki.poulose@arm.com>,
"Kan Liang" <kan.liang@linux.intel.com>,
"Raul Silvera" <rsilvera@google.com>,
"Athira Rajeev" <atrajeev@linux.vnet.ibm.com>,
"Ravi Bangoria" <ravi.bangoria@amd.com>,
"Florian Fischer" <florian.fischer@muhq.space>,
"Rob Herring" <robh@kernel.org>,
"Xing Zhengjun" <zhengjun.xing@linux.intel.com>,
"Sean Christopherson" <seanjc@google.com>,
"Chengdong Li" <chengdongli@tencent.com>,
"Denis Nikitin" <denik@chromium.org>,
"Martin Liška" <mliska@suse.cz>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org
Subject: Re: [PATCH v1 0/6] Simplify linking against tools/perf code
Date: Tue, 28 Mar 2023 20:11:33 +0300 [thread overview]
Message-ID: <cf2bd4c9-c895-2533-cce2-28e9d6b89f1f@intel.com> (raw)
In-Reply-To: <CAP-5=fV749yr+wMMYjm87ThnM7ESd+i4Ko=+6H+cuCNdKJM50A@mail.gmail.com>
On 28/03/23 19:14, Ian Rogers wrote:
> On Tue, Mar 28, 2023 at 6:24 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>
>> On 28/03/23 04:40, Ian Rogers wrote:
>>> When fuzzing something like parse-events, having the main function in
>>> perf.c alongside global variables like input_name means that
>>> input_name must be redeclared with the fuzzer function's
>>> main. However, as the fuzzer is using the tools/perf code as a library
>>> this causes backward linking reference that the linker may warn
>>> about. Reorganize perf.c and perf.h to avoid potential backward
>>> references, or so that the declaration/definition locations are more
>>> consistent.
>>>
>>
>> Seems like it could be a pain to maintain.
>>
>> Did you consider just adding:
>>
>> diff --git a/tools/perf/perf.c b/tools/perf/perf.c
>> index 82bbe0ca858b..a75dd47d68ee 100644
>> --- a/tools/perf/perf.c
>> +++ b/tools/perf/perf.c
>> @@ -456,6 +456,7 @@ static int libperf_print(enum libperf_print_level level,
>> return veprintf(level, verbose, fmt, ap);
>> }
>>
>> +#ifndef CUSTOM_MAIN
>> int main(int argc, const char **argv)
>> {
>> int err;
>> @@ -576,3 +577,4 @@ int main(int argc, const char **argv)
>> out:
>> return 1;
>> }
>> +#endif
>>
>
> It's possible. Would need to make the static functions not warn about
> being declared and not used. I still think that just aligning
> definitions and declarations yields the most expected code and will
> lead to fewer problems in the long run.
Making perf source dependent on an unknown derivative makes
things more complicated.
If you are not going to contribute it to perf, then a
suggestion is along the lines of the following:
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 82bbe0ca858b..6a7fe1534664 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -456,7 +456,18 @@ static int libperf_print(enum libperf_print_level level,
return veprintf(level, verbose, fmt, ap);
}
$ git diff
+#ifdef CUSTOM_MAIN
+int main(void)
+{
+ printf("This is not perf\n");
+ return 0;
+}
+
+int perf_main(int argc, const char **argv);
+int perf_main(int argc, const char **argv)
+#else
int main(int argc, const char **argv)
+#endif
{
int err;
const char *cmd;
$ make EXTRA_CFLAGS="-DCUSTOM_MAIN" NO_BPF_SKEL=1 -C tools/perf >/dev/null
Warning: Kernel ABI header at 'tools/include/uapi/linux/in.h' differs from latest version at 'include/uapi/linux/in.h'
Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' differs from latest version at 'arch/x86/include/asm/cpufeatures.h'
Warning: Kernel ABI header at 'tools/arch/arm64/include/uapi/asm/perf_regs.h' differs from latest version at 'arch/arm64/include/uapi/asm/perf_regs.h'
Warning: Kernel ABI header at 'tools/include/linux/coresight-pmu.h' differs from latest version at 'include/linux/coresight-pmu.h'
Makefile.config:587: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:805: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev
Makefile.config:1046: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
Makefile.config:1075: No alternatives command found, you need to set JDIR= to point to the root of your Java directory
Makefile.config:1137: libpfm4 not found, disables libpfm4 support. Please install libpfm4-dev
$ tools/perf/perf version
This is not perf
next prev parent reply other threads:[~2023-03-28 17:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 1:40 Ian Rogers
2023-03-28 1:40 ` [PATCH v1 1/6] perf ui: Move window resize signal functions Ian Rogers
2023-03-28 1:40 ` [PATCH v1 2/6] perf usage: Move usage strings Ian Rogers
2023-03-28 1:40 ` [PATCH v1 3/6] perf header: Move perf_version_string declaration Ian Rogers
2023-03-28 1:40 ` [PATCH v1 4/6] perf version: Use regular verbose flag Ian Rogers
2023-03-28 1:40 ` [PATCH v1 5/6] perf util: Move input_name to util Ian Rogers
2023-03-28 1:40 ` [PATCH v1 6/6] perf util: Move perf_guest/host declarations Ian Rogers
2023-03-28 13:24 ` [PATCH v1 0/6] Simplify linking against tools/perf code Adrian Hunter
2023-03-28 16:14 ` Ian Rogers
2023-03-28 17:11 ` Adrian Hunter [this message]
2023-03-28 17:42 ` Ian Rogers
2023-03-30 5:39 ` Adrian Hunter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf2bd4c9-c895-2533-cce2-28e9d6b89f1f@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=chengdongli@tencent.com \
--cc=coresight@lists.linaro.org \
--cc=denik@chromium.org \
--cc=florian.fischer@muhq.space \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=mliska@suse.cz \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=robh@kernel.org \
--cc=rsilvera@google.com \
--cc=seanjc@google.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=zhengjun.xing@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®