kernel/linux.git/tools/perf/Makefile.config, branch v5.10.257

perf build: Warn when libdebuginfod devel files are not available

2025-06-27T10:04:05+00:00

[ Upstream commit 4fce4b91fd1aabb326c46e237eb4b19ab72598f8 ] While working on 'perf version --build-options' I noticed that: $ perf version --build-options perf version 6.15.rc1.g312a07a00d31 aio: [ on ] # HAVE_AIO_SUPPORT bpf: [ on ] # HAVE_LIBBPF_SUPPORT bpf_skeletons: [ on ] # HAVE_BPF_SKEL debuginfod: [ OFF ] # HAVE_DEBUGINFOD_SUPPORT And looking at tools/perf/Makefile.config I also noticed that it is not opt-in, meaning we will attempt to build with it in all normal cases. So add the usual warning at build time to let the user know that something recommended is missing, now we see: Makefile.config:563: No elfutils/debuginfod.h found, no debuginfo server support, please install elfutils-debuginfod-client-devel or equivalent And after following the recommendation: $ perf check feature debuginfod debuginfod: [ on ] # HAVE_DEBUGINFOD_SUPPORT $ ldd ~/bin/perf | grep debuginfo libdebuginfod.so.1 => /lib64/libdebuginfod.so.1 (0x00007fee5cf5f000) $ With this feature on several perf tools will fetch what is needed and not require all the contents of the debuginfo packages, for instance: # rpm -qa | grep kernel-debuginfo # pahole --running_kernel_vmlinux pahole: couldn't find a vmlinux that matches the running kernel HINT: Maybe you're inside a container or missing a debuginfo package? # # perf trace -e open* perf probe --vars icmp_rcv 0.000 ( 0.005 ms): perf/97391 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: RDONLY|CLOEXEC) = 3 0.014 ( 0.004 ms): perf/97391 openat(dfd: CWD, filename: "/lib64/libm.so.6", flags: RDONLY|CLOEXEC) = 3 32130.100 ( 0.008 ms): perf/97391 openat(dfd: CWD, filename: "/root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo") = 3 Available variables at icmp_rcv @ struct sk_buff* skb # # pahole --running_kernel_vmlinux /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo # file /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=aa3c82b4a13f9c0e0301bebb20fe958c4db6f362, with debug_info, not stripped # ls -la /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo -r--------. 1 root root 475401512 Mar 27 21:00 /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo # Then, cached: # perf stat --null perf probe --vars icmp_rcv Available variables at icmp_rcv @ struct sk_buff* skb Performance counter stats for 'perf probe --vars icmp_rcv': 0.671389041 seconds time elapsed 0.519176000 seconds user 0.150860000 seconds sys Fixes: c7a14fdcb3fa7736 ("perf build-ids: Fall back to debuginfod query if debuginfo not found") Tested-by: Ingo Molnar Cc: Adrian Hunter Cc: Dmitriy Vyukov Cc: Howard Chu Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Frank Ch. Eigler Link: https://lore.kernel.org/r/Z_dkNDj9EPFwPqq1@gmail.com [ Folded patch from Ingo to have the debian/ubuntu devel package added build warning message ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

perf tools: Add an option to build without libbfd

2023-09-23T09:01:08+00:00

[ Upstream commit 0d1c50ac488ebdaeeaea8ed5069f8d435fd485ed ] Some distributions, like debian, don't link perf with libbfd. Add a build flag to make this configuration buildable and testable. This was inspired by: https://lore.kernel.org/linux-perf-users/20210910102307.2055484-1-tonyg@leastfixedpoint.com/T/#u Signed-off-by: Ian Rogers Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: tony garnock-jones Link: http://lore.kernel.org/lkml/20210910225756.729087-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 7822a8913f4c ("perf build: Update build rule for generated files") Signed-off-by: Sasha Levin

perf python: Fix build when PYTHON_CONFIG is user supplied

2022-08-31T15:15:24+00:00

commit bc9e7fe313d5e56d4d5f34bcc04d1165f94f86fb upstream. The previous change to Python autodetection had a small mistake where the auto value was used to determine the Python binary, rather than the user supplied value. The Python binary is only used for one part of the build process, rather than the final linking, so it was producing correct builds in most scenarios, especially when the auto detected value matched what the user wanted, or the system only had a valid set of Pythons. Change it so that the Python binary path is derived from either the PYTHON_CONFIG value or PYTHON value, depending on what is specified by the user. This was the original intention. This error was spotted in a build failure an odd cross compilation environment after commit 4c41cb46a732fe82 ("perf python: Prefer python3") was merged. Fixes: 630af16eee495f58 ("perf tools: Use Python devtools for version autodetection rather than runtime") Signed-off-by: James Clark Acked-by: Ian Rogers Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20220728093946.1337642-1-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf tools: Use Python devtools for version autodetection rather than runtime

2022-06-09T08:21:05+00:00

[ Upstream commit 630af16eee495f583db5202c3613d1b191f10694 ] This fixes the issue where the build will fail if only the Python2 runtime is installed but the Python3 devtools are installed. Currently the workaround is 'make PYTHON=python3'. Fix it by autodetecting Python based on whether python[x]-config exists rather than just python[x] because both are needed for the build. Then -config is stripped to find the Python runtime. Testing ======= * Auto detect links with Python3 when the v3 devtools are installed and only Python 2 runtime is installed * Auto detect links with Python2 when both devtools are installed * Sensible warning is printed if no Python devtools are installed * 'make PYTHON=x' still automatically sets PYTHON_CONFIG=x-config * 'make PYTHON=x' fails if x-config doesn't exist * 'make PYTHON=python3' overrides Python2 devtools * 'make PYTHON=python2' overrides Python3 devtools * 'make PYTHON_CONFIG=x-config' works * 'make PYTHON=x PYTHON_CONFIG=x' works * 'make PYTHON=missing' reports an error * 'make PYTHON_CONFIG=missing' reports an error Fixes: 79373082fa9de8be ("perf python: Autodetect python3 binary") Signed-off-by: James Clark Cc: Alexander Shishkin Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Link: https://lore.kernel.org/r/20220309194313.3350126-2-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

tools build: Filter out options and warnings not supported by clang

2022-04-13T19:01:10+00:00

commit 41caff459a5b956b3e23ba9ca759dd0629ad3dda upstream. These make the feature check fail when using clang, so remove them just like is done in tools/perf/Makefile.config to build perf itself. Adding -Wno-compound-token-split-by-macro to tools/perf/Makefile.config when building with clang is also necessary to avoid these warnings turned into errors (-Werror): CC /tmp/build/perf/util/scripting-engines/trace-event-perl.o In file included from util/scripting-engines/trace-event-perl.c:35: In file included from /usr/lib64/perl5/CORE/perl.h:4085: In file included from /usr/lib64/perl5/CORE/hv.h:659: In file included from /usr/lib64/perl5/CORE/hv_func.h:34: In file included from /usr/lib64/perl5/CORE/sbox32_hash.h:4: /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '(' and '{' tokens introducing statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro] ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/perl5/CORE/zaphod32_hash.h:80:38: note: expanded from macro 'ZAPHOD32_SCRAMBLE32' #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START { \ ^~~~~~~~~~ /usr/lib64/perl5/CORE/perl.h:737:29: note: expanded from macro 'STMT_START' # define STMT_START (void)( /* gcc supports "({ STATEMENTS; })" */ ^ /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: '{' token is here ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/perl5/CORE/zaphod32_hash.h:80:49: note: expanded from macro 'ZAPHOD32_SCRAMBLE32' #define ZAPHOD32_SCRAMBLE32(v,prime) STMT_START { \ ^ /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: error: '}' and ')' tokens terminating statement expression appear in different macro expansion contexts [-Werror,-Wcompound-token-split-by-macro] ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/perl5/CORE/zaphod32_hash.h:87:41: note: expanded from macro 'ZAPHOD32_SCRAMBLE32' v ^= (v>>23); \ ^ /usr/lib64/perl5/CORE/zaphod32_hash.h:150:5: note: ')' token is here ZAPHOD32_SCRAMBLE32(state[0],0x9fade23b); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/perl5/CORE/zaphod32_hash.h:88:3: note: expanded from macro 'ZAPHOD32_SCRAMBLE32' } STMT_END ^~~~~~~~ /usr/lib64/perl5/CORE/perl.h:738:21: note: expanded from macro 'STMT_END' # define STMT_END ) ^ Please refer to the discussion on the Link: tag below, where Nathan clarifies the situation: acme> And then get to the problems at the end of this message, which seem acme> similar to the problem described here: acme> acme> From Nathan Chancellor <> acme> Subject [PATCH] mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO acme> acme> https://lkml.org/lkml/2020/9/1/135 acme> acme> So perhaps in this case its better to disable that acme> -Werror,-Wcompound-token-split-by-macro when building with clang? Yes, I think that is probably the best solution. As far as I can tell, at least in this file and context, the warning appears harmless, as the "create a GNU C statement expression from two different macros" is very much intentional, based on the presence of PERL_USE_GCC_BRACE_GROUPS. The warning is fixed in upstream Perl by just avoiding creating GNU C statement expressions using STMT_START and STMT_END: https://github.com/Perl/perl5/issues/18780 https://github.com/Perl/perl5/pull/18984 If I am reading the source code correctly, an alternative to disabling the warning would be specifying -DPERL_GCC_BRACE_GROUPS_FORBIDDEN but it seems like that might end up impacting more than just this site, according to the issue discussion above. Based-on-a-patch-by: Sedat Dilek Tested-by: Sedat Dilek # Debian/Selfmade LLVM-14 (x86-64) Cc: Adrian Hunter Cc: Fangrui Song Cc: Florian Fainelli Cc: Ian Rogers Cc: Jiri Olsa Cc: John Keeping Cc: Leo Yan Cc: Michael Petlan Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Link: http://lore.kernel.org/lkml/YkxWcYzph5pC1EK8@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf build: Don't use -ffat-lto-objects in the python feature test when building with clang-13

2022-04-13T19:01:09+00:00

commit 3a8a0475861a443f02e3a9b57d044fe2a0a99291 upstream. Using -ffat-lto-objects in the python feature test when building with clang-13 results in: clang-13: error: optimization flag '-ffat-lto-objects' is not supported [-Werror,-Wignored-optimization-argument] error: command '/usr/sbin/clang' failed with exit code 1 cp: cannot stat '/tmp/build/perf/python_ext_build/lib/perf*.so': No such file or directory make[2]: *** [Makefile.perf:639: /tmp/build/perf/python/perf.so] Error 1 Noticed when building on a docker.io/library/archlinux:base container. Cc: Adrian Hunter Cc: Fangrui Song Cc: Florian Fainelli Cc: Ian Rogers Cc: Jiri Olsa Cc: John Keeping Cc: Leo Yan Cc: Michael Petlan Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Sedat Dilek Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

tools build: Remove needless libpython-version feature check that breaks test-all fast path

2021-12-14T10:32:42+00:00

commit 3d1d57debee2d342a47615707588b96658fabb85 upstream. Since 66dfdff03d196e51 ("perf tools: Add Python 3 support") we don't use the tools/build/feature/test-libpython-version.c version in any Makefile feature check: $ find tools/ -type f | xargs grep feature-libpython-version $ The only place where this was used was removed in 66dfdff03d196e51: - ifneq ($(feature-libpython-version), 1) - $(warning Python 3 is not yet supported; please set) - $(warning PYTHON and/or PYTHON_CONFIG appropriately.) - $(warning If you also have Python 2 installed, then) - $(warning try something like:) - $(warning $(and ,)) - $(warning $(and ,) make PYTHON=python2) - $(warning $(and ,)) - $(warning Otherwise, disable Python support entirely:) - $(warning $(and ,)) - $(warning $(and ,) make NO_LIBPYTHON=1) - $(warning $(and ,)) - $(error $(and ,)) - else - LDFLAGS += $(PYTHON_EMBED_LDFLAGS) - EXTLIBS += $(PYTHON_EMBED_LIBADD) - LANG_BINDINGS += $(obj-perf)python/perf.so - $(call detected,CONFIG_LIBPYTHON) - endif And nowadays we either build with PYTHON=python3 or just install the python3 devel packages and perf will build against it. But the leftover feature-libpython-version check made the fast path feature detection to break in all cases except when python2 devel files were installed: $ rpm -qa | grep python.*devel python3-devel-3.9.7-1.fc34.x86_64 $ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; $ make -C tools/perf O=/tmp/build/perf install-bin make: Entering directory '/var/home/acme/git/perf/tools/perf' BUILD: Doing 'make -j32' parallel build HOSTCC /tmp/build/perf/fixdep.o $ cat /tmp/build/perf/feature/test-all.make.output In file included from test-all.c:18: test-libpython-version.c:5:10: error: #error 5 | #error | ^~~~~ $ ldd ~/bin/perf | grep python libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x00007fda6dbcf000) $ As python3 is the norm these days, fix this by just removing the unused feature-libpython-version feature check, making the test-all fast path to work with the common case. With this: $ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; $ make -C tools/perf O=/tmp/build/perf install-bin |& head make: Entering directory '/var/home/acme/git/perf/tools/perf' BUILD: Doing 'make -j32' parallel build HOSTCC /tmp/build/perf/fixdep.o HOSTLD /tmp/build/perf/fixdep-in.o LINK /tmp/build/perf/fixdep Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] $ ldd ~/bin/perf | grep python libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x00007f58800b0000) $ cat /tmp/build/perf/feature/test-all.make.output $ Reviewed-by: James Clark Fixes: 66dfdff03d196e51 ("perf tools: Add Python 3 support") Cc: Adrian Hunter Cc: Ian Rogers Cc: Jaroslav Škarvada Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lore.kernel.org/lkml/YaYmeeC6CS2b8OSz@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf unwind: Do not overwrite FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64}

2021-09-22T10:28:04+00:00

[ Upstream commit cdf32b44678c382a31dc183d9a767306915cda7b ] When setting LIBUNWIND_DIR, we first set FEATURE_CHECK_LDFLAGS-libunwind-{aarch64,x86} = -L$(LIBUNWIND_DIR)/lib. This happens a bit before, the overwritting, in: libunwind_arch_set_flags = $(eval $(libunwind_arch_set_flags_code)) define libunwind_arch_set_flags_code FEATURE_CHECK_CFLAGS-libunwind-$(1) = -I$(LIBUNWIND_DIR)/include FEATURE_CHECK_LDFLAGS-libunwind-$(1) = -L$(LIBUNWIND_DIR)/lib endef ifdef LIBUNWIND_DIR LIBUNWIND_CFLAGS = -I$(LIBUNWIND_DIR)/include LIBUNWIND_LDFLAGS = -L$(LIBUNWIND_DIR)/lib LIBUNWIND_ARCHS = x86 x86_64 arm aarch64 debug-frame-arm debug-frame-aarch64 $(foreach libunwind_arch,$(LIBUNWIND_ARCHS),$(call libunwind_arch_set_flags,$(libunwind_arch))) endif Look at that 'foreach' on all the LIBUNWIND_ARCHS. After commit 5c4d7c82c0dc ("perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC"), FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64} is overwritten. As a result, the remote libunwind libraries cannot be searched from $(LIBUNWIND_DIR)/lib directory during feature check tests. Fix it with variable appending. Before this patch: perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64 BUILD: Doing 'make -j16' parallel build ... ... libopencsd: [ OFF ] ... libunwind-x86: [ OFF ] ... libunwind-x86_64: [ OFF ] ... libunwind-arm: [ OFF ] ... libunwind-aarch64: [ OFF ] ... libunwind-debug-frame: [ OFF ] ... libunwind-debug-frame-arm: [ OFF ] ... libunwind-debug-frame-aarch64: [ OFF ] ... cxx: [ OFF ] perf$ cat ../build/feature/test-libunwind-aarch64.make.output /usr/bin/ld: cannot find -lunwind-aarch64 /usr/bin/ld: cannot find -lunwind-aarch64 collect2: error: ld returned 1 exit status After this patch: perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64 BUILD: Doing 'make -j16' parallel build ... libopencsd: [ OFF ] ... libunwind-x86: [ OFF ] ... libunwind-x86_64: [ OFF ] ... libunwind-arm: [ OFF ] ... libunwind-aarch64: [ on ] ... libunwind-debug-frame: [ OFF ] ... libunwind-debug-frame-arm: [ OFF ] ... libunwind-debug-frame-aarch64: [ OFF ] ... cxx: [ OFF ] perf$ cat ../build/feature/test-libunwind-aarch64.make.output perf$ ldd ./perf linux-vdso.so.1 (0x00007ffdf07da000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f30953dc000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f30951d4000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3094e36000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3094c32000) libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f3094a18000) libdw.so.1 => /usr/lib/x86_64-linux-gnu/libdw.so.1 (0x00007f30947cc000) libunwind-x86_64.so.8 => /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8 (0x00007f30945ad000) libunwind.so.8 => /usr/lib/x86_64-linux-gnu/libunwind.so.8 (0x00007f3094392000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f309416c000) libunwind-aarch64.so.8 => not found libslang.so.2 => /lib/x86_64-linux-gnu/libslang.so.2 (0x00007f3093c8a000) libpython2.7.so.1.0 => /usr/local/lib/libpython2.7.so.1.0 (0x00007f309386b000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f309364e000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f3093443000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3093052000) /lib64/ld-linux-x86-64.so.2 (0x00007f3096097000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3092e42000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3092c3f000) Fixes: 5c4d7c82c0dceccf ("perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC") Signed-off-by: Li Huafei Cc: Alexander Shishkin Cc: He Kuang Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zhang Jinhao Link: http://lore.kernel.org/lkml/20210823134340.60955-1-lihuafei1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

perf tools: Fix dynamic libbpf link

2021-05-19T08:13:13+00:00

[ Upstream commit ad1237c30d975535a669746496cbed136aa5a045 ] Justin reported broken build with LIBBPF_DYNAMIC=1. When linking libbpf dynamically we need to use perf's hashmap object, because it's not exported in libbpf.so (only in libbpf.a). Following build is now passing: $ make LIBBPF_DYNAMIC=1 BUILD: Doing 'make -j8' parallel build ... $ ldd perf | grep libbpf libbpf.so.0 => /lib64/libbpf.so.0 (0x00007fa7630db000) Fixes: eee19501926d ("perf tools: Grab a copy of libbpf's hashmap") Reported-by: Justin M. Forbes Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Ian Rogers Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210508205020.617984-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

perf tools: Remove LTO compiler options when building perl support

2020-11-03T11:24:54+00:00

To avoid breaking the build by mixing files compiled with things coming from distro specific compiler options for perl with the rest of perf, i.e. to avoid this: `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of /tmp/build/perf/util/scripting-engines/perf-in.o: defined in discarded section `.gnu.debuglto_.debug_macro[wm4.stdcpredef.h.19.8dc41bed5d9037ff9622e015fb5f0ce3]' of /tmp/build/perf/util/scripting-engines/perf-in.o Noticed on Fedora 33. Signed-off-by: Justin M. Forbes Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1593431 Cc: Jiri Olsa Link: https://src.fedoraproject.org/rpms/kernel-tools/c/589a32b62f0c12516ab7b34e3dd30d450145bfa4?branch=master Signed-off-by: Arnaldo Carvalho de Melo