[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181022025742.GA23616@andestech.com>
Date: Mon, 22 Oct 2018 10:57:43 +0800
From: Nick Hu <nickhu@...estech.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
CC: Greentime Ying-Han Hu(胡英漢)
<greentime@...estech.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
"Ingo Molnar" <mingo@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
"Namhyung Kim" <namhyung@...nel.org>,
"deanbo422@...il.com" <deanbo422@...il.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"green.hu@...il.com" <green.hu@...il.com>
Subject: Re: [PATCH 1/1] Perf: Compile failed when compile with libelf.
Hi Arnaldo,
On Thu, Oct 18, 2018 at 10:56:10PM +0800, Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 18, 2018 at 04:36:46PM +0800, Nickhu escreveu:
> > The error message:
> > =====================================================================
> > util/symbol-elf.c:46:12: error: static declaration of 'elf_getphdrnum'
> > follows non-static declaration
> > static int elf_getphdrnum(Elf *elf, size_t *dst)
> > ^~~~~~~~~~~~~~
> > In file included from util/symbol.h:20,
> > from util/symbol-elf.c:9:
> > /local/nickhu/build-system-3/toolchain/nds32le-linux-glibc-v3-upstream/
> > nds32le-linux/sysroot/usr/include/libelf.h:266:12: note: previous declaration
> > of 'elf_getphdrnum' was here
> > extern int elf_getphdrnum (Elf *__elf, size_t *__dst);
> > ^~~~~~~~~~~~~~
> > util/symbol-elf.c:62:12: error: static declaration of 'elf_getshdrstrndx'
> > follows non-static declaration
> > static int elf_getshdrstrndx(Elf *elf __maybe_unused, size_t *dst __maybe
> > _unused)
> > ^~~~~~~~~~~~~~~~~
> > In file included from util/symbol.h:20,
> > from util/symbol-elf.c:9:
> > /local/nickhu/build-system-3/toolchain/nds32le-linux-glibc-v3-upstream/
> > nds32le-linux/sysroot/usr/include/libelf.h:316:12: note: previous declaration
> > of 'elf_getshdrstrndx' was here
> > extern int elf_getshdrstrndx (Elf *__elf, size_t *__dst);
> > =====================================================================
> >
> > Fix it.
>
> Humm, I think the fix lies elsewhere.
>
> If you find that function in a header, then its probably because you
> _have_ it in your system, right? In that case
> HAVE_ELF_GETPHDRNUM_SUPPORT should be defined and that elf_getphdrnum()
> fallback implementation should not be compiled.
>
> So looking at where HAVE_ELF_GETPHDRNUM_SUPPORT is defined, in
> tools/build/feature, more specifically here:
>
> [acme@...et perf]$ cat tools/build/feature/test-libelf-getphdrnum.c
> // SPDX-License-Identifier: GPL-2.0
> #include <libelf.h>
>
> int main(void)
> {
> size_t dst;
>
> return elf_getphdrnum(0, &dst);
> }
> [acme@...et perf]$
>
> [acme@...et perf]$ find tools/ -type f | xargs grep HAVE_ELF_GETPHDRNUM_SUPPORT
> tools/perf/Makefile.config: CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
> tools/perf/util/symbol-elf.c:#ifndef HAVE_ELF_GETPHDRNUM_SUPPORT
> [acme@...et perf]$
>
> Can you take a look at:
>
> [acme@...et perf]$ ls -la /tmp/build/perf/feature/test-libelf-getphdrnum.*
> -rwxrwxr-x. 1 acme acme 8240 Oct 17 09:20 /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> -rw-rw-r--. 1 acme acme 1373 Oct 17 09:20 /tmp/build/perf/feature/test-libelf-getphdrnum.d
> -rw-rw-r--. 1 acme acme 0 Oct 17 09:20 /tmp/build/perf/feature/test-libelf-getphdrnum.make.output
> [acme@...et perf]$
>
> So in my case, using this libelf:
>
> [acme@...et perf]$ rpm -qf /usr/include/libelf.h
> elfutils-libelf-devel-0.173-1.fc28.x86_64
> [acme@...et perf]$
>
> the .make.output file is empty, the build was successful, without
> warnings, that binary was generated:
>
> [acme@...et perf]$ ls -la /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> -rwxrwxr-x. 1 acme acme 8240 Oct 17 09:20 /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> [acme@...et perf]$ ldd /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> linux-vdso.so.1 (0x00007ffdf93ea000)
> libelf.so.1 => /lib64/libelf.so.1 (0x00007efc3f2d7000)
> libc.so.6 => /lib64/libc.so.6 (0x00007efc3ef21000)
> libz.so.1 => /lib64/libz.so.1 (0x00007efc3ed0a000)
> /lib64/ld-linux-x86-64.so.2 (0x00007efc3f4ef000)
> [acme@...et perf]$ nm /tmp/build/perf/feature/test-libelf-getphdrnum.bin | grep getphdrnum
> U elf_getphdrnum@@ELFUTILS_1.6
> [acme@...et perf]$
>
> And here are the headers used:
>
> [acme@...et perf]$ cat /tmp/build/perf/feature/test-libelf-getphdrnum.d
> /tmp/build/perf/feature/test-libelf-getphdrnum.bin: \
> test-libelf-getphdrnum.c /usr/include/stdc-predef.h \
> /usr/include/libelf.h \
> /usr/lib/gcc/x86_64-redhat-linux/7/include/stdint.h \
> /usr/include/stdint.h /usr/include/bits/libc-header-start.h \
> /usr/include/features.h /usr/include/sys/cdefs.h \
> /usr/include/bits/wordsize.h /usr/include/bits/long-double.h \
> /usr/include/gnu/stubs.h /usr/include/gnu/stubs-64.h \
> /usr/include/bits/types.h /usr/include/bits/typesizes.h \
> /usr/include/bits/wchar.h /usr/include/bits/stdint-intn.h \
> /usr/include/bits/stdint-uintn.h /usr/include/sys/types.h \
> /usr/include/bits/types/clock_t.h /usr/include/bits/types/clockid_t.h \
> /usr/include/bits/types/time_t.h /usr/include/bits/types/timer_t.h \
> /usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h \
> /usr/include/endian.h /usr/include/bits/endian.h \
> /usr/include/bits/byteswap.h /usr/include/bits/byteswap-16.h \
> /usr/include/bits/uintn-identity.h /usr/include/sys/select.h \
> /usr/include/bits/select.h /usr/include/bits/types/sigset_t.h \
> /usr/include/bits/types/__sigset_t.h \
> /usr/include/bits/types/struct_timeval.h \
> /usr/include/bits/types/struct_timespec.h /usr/include/sys/sysmacros.h \
> /usr/include/bits/sysmacros.h /usr/include/bits/pthreadtypes.h \
> /usr/include/bits/thread-shared-types.h \
> /usr/include/bits/pthreadtypes-arch.h /usr/include/elf.h
> [acme@...et perf]$
>
> So, taking this into account, I think the feature test is using a
> different include path than the tool, which may be a real bug in the
> feature detection, how is the command line that led to this?
>
> One other way to see that the feature test is not detecting that
> library, use VF=1 after a clean and check if this line is present:
>
> ... libelf-getphdrnum: [ OFF ]
>
> [acme@...et perf]$ rm -rf /tmp/build/perf/ ; mkdir -p /tmp/build/perf
> [acme@...et perf]$ time make VF=1 -C tools/perf O=/tmp/build/perf
> make: Entering directory '/home/acme/git/perf/tools/perf'
> BUILD: Doing 'make -j4' parallel build
> HOSTCC /tmp/build/perf/fixdep.o
> HOSTLD /tmp/build/perf/fixdep-in.o
> LINK /tmp/build/perf/fixdep
> Warning: Kernel ABI header at 'tools/include/uapi/linux/mman.h' differs from latest version at 'include/uapi/linux/mman.h'
> diff -u tools/include/uapi/linux/mman.h include/uapi/linux/mman.h
>
> Auto-detecting system features:
> ... dwarf: [ on ]
> ... dwarf_getlocations: [ on ]
> ... glibc: [ on ]
> ... gtk2: [ on ]
> ... libaudit: [ on ]
> ... libbfd: [ on ]
> ... libelf: [ on ]
> ... libnuma: [ on ]
> ... numa_num_possible_cpus: [ on ]
> ... libperl: [ on ]
> ... libpython: [ on ]
> ... libslang: [ on ]
> ... libcrypto: [ on ]
> ... libunwind: [ on ]
> ... libdw-dwarf-unwind: [ on ]
> ... zlib: [ on ]
> ... lzma: [ on ]
> ... get_cpuid: [ on ]
> ... bpf: [ on ]
> ... backtrace: [ on ]
> ... fortify-source: [ on ]
> ... sync-compare-and-swap: [ on ]
> ... gtk2-infobar: [ on ]
> ... libelf-getphdrnum: [ on ]
> ... libelf-gelf_getnote: [ on ]
> ... libelf-getshdrstrndx: [ on ]
> ... libelf-mmap: [ on ]
> ... libpython-version: [ on ]
> ... libunwind-x86: [ OFF ]
> ... libunwind-x86_64: [ on ]
> ... libunwind-arm: [ OFF ]
> ... libunwind-aarch64: [ OFF ]
> ... pthread-attr-setaffinity-np: [ on ]
> ... pthread-barrier: [ on ]
> ... reallocarray: [ on ]
> ... stackprotector-all: [ on ]
> ... timerfd: [ on ]
> ... sched_getcpu: [ on ]
> ... sdt: [ on ]
> ... setns: [ on ]
> ... libopencsd: [ OFF ]
Thank your for the quick reply. Your advices are very helpful to me.
Unfortunately, I can't reproduce the problem now. When I try to
reproduce the problem, it just compiled success. I guess maybe I have
something not clean cause the problem then.
I will drop my patch, thanks!
Powered by blists - more mailing lists