Re: perf build broken in 5.1-rc7
From: Arnaldo Carvalho de Melo
Date: Wed May 01 2019 - 09:08:09 EST
Em Tue, Apr 30, 2019 at 04:31:14PM +0300, Thomas Backlund escreveu:
>
> Den 30-04-2019 kl. 16:06, skrev Song Liu:
> > On Tue, Apr 30, 2019 at 12:55 AM Thomas Backlund <tmb@xxxxxxxxxx> wrote:
> > > Den 30-04-2019 kl. 10:26, skrev Thomas Backlund:
> > > > Building perf in 5.1-rc5/6/7 fails:
> > > > Build start:
> > > > make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1
> > > > WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1
> > > > NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all
> > > > BUILD: Doing 'make -j32' parallel build
> > > > HOSTCC fixdep.o
> > > > HOSTLD fixdep-in.o
> > > > LINK fixdep
> > > > Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h'
> > > > differs from latest version at 'arch/x86/include/uapi/asm/vmx.h'
> > > > diff -u tools/arch/x86/include/uapi/asm/vmx.h
> > > > arch/x86/include/uapi/asm/vmx.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 ]
> > > > ... libaio: [ on ]
> > > > ... disassembler-four-args: [ OFF ]
> > > >
> > > > Makefile.config:473: No sys/sdt.h found, no SDT events are defined,
> > > > please install systemtap-sdt-devel or systemtap-sdt-dev
> > > > Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF
> > > > format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
> > > >
> > > >
> > > > And breaks with:
> > > >
> > > >
> > > > CC ui/setup.o
> > > > util/annotate.c: In function 'symbol__disassemble_bpf':
> > > > util/annotate.c:1767:29: error: incompatible type for argument 1 of
> > > > 'disassembler'
> > > > disassemble = disassembler(bfdf);
> > > > ^~~~
> > > > In file included from util/annotate.c:1689:
> > > > /usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture'
> > > > but argument is of type 'bfd *' {aka 'struct bfd *'}
> > > > extern disassembler_ftype disassembler (enum bfd_architecture arc,
> > > > ~~~~~~~~~~~~~~~~~~~~~~^~~
> > > > util/annotate.c:1767:16: error: too few arguments to function
> > > > 'disassembler'
> > > > disassemble = disassembler(bfdf);
> > > > ^~~~~~~~~~~~
> > > > In file included from util/annotate.c:1689:
> > > > /usr/include/dis-asm.h:325:27: note: declared here
> > > > extern disassembler_ftype disassembler (enum bfd_architecture arc,
> > > > ^~~~~~~~~~~~
> > > > CC arch/x86/util/header.o
> > > > CC arch/x86/util/tsc.o
> > > > CC arch/x86/util/pmu.o
> > > > mv: cannot stat 'util/.annotate.o.tmp': No such file or directory
> > > > CC bench/futex-requeue.o
> > > > CC arch/x86/util/kvm-stat.o
> > > > make[4]: ***
> > > > [/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97:
> > > > util/annotate.o] Error 1
> > > > make[4]: *** Waiting for unfinished jobs....
> > > > CC util/build-id.o
> > > >
> > > >
> > > >
> > >
> > > And I forgot...
> > >
> > > Reverting:
> > > From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001
> > > From: Song Liu <songliubraving@xxxxxx>
> > > Date: Mon, 11 Mar 2019 22:30:48 -0700
> > > Subject: perf annotate: Enable annotation of BPF programs
> > >
> > > Makes it build again.
> > >
> > > --
> > > Thomas
> > >
> > Hi Thomas,
> >
> > Which system are you running this test on? I would like to repro it in a VM.
> >
> > Thanks,
> > Song
>
>
> Mageia Cauldron currently stabilizing to become Mageia 7 in ~1 month.
>
>
> Basesystem is:
>
> binutils-2.32-5.mga7
> (includes all fixes from upstream binutils-2_32-branch)
>
> gcc-8.3.1-0.20190419.2.mga7
>
> glibc-2.29-7.mga7
> (includes all fixes from upstream glibc release/2.29/master branch up to
> 2019-04-15 for now)
>
>
> kernel-desktop-5.1.0-0.rc7.1.mga7
> kernel-userspace-headers-5.1.0-0.rc7.1.mga7
Ok, so the steps are:
1) the feature test, the small C program that we try to build is:
[acme@quaco perf]$ cat tools/build/feature/test-disassembler-four-args.c
// SPDX-License-Identifier: GPL-2.0
#include <bfd.h>
#include <dis-asm.h>
int main(void)
{
bfd *abfd = bfd_openr(NULL, NULL);
disassembler(bfd_get_arch(abfd),
bfd_big_endian(abfd),
bfd_get_mach(abfd),
abfd);
return 0;
}
[acme@quaco perf]$
And here in my fedora29 system it ends up producing the following file,
when built with:
$ make O=/tmp/build/perf -C tools/perf install-bin
[acme@quaco perf]$ cat /tmp/build/perf/feature/test-disassembler-four-args.make.output
[acme@quaco perf]$
[acme@quaco perf]$ file /tmp/build/perf/feature/test-disassembler-four-args.bin
/tmp/build/perf/feature/test-disassembler-four-args.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c9bd83db766a620c5cb6d756b0cd6991527641ff, not stripped, too many notes (256)
[acme@quaco perf]$ ldd /tmp/build/perf/feature/test-disassembler-four-args.bin
linux-vdso.so.1 (0x00007ffebc5f9000)
libz.so.1 => /lib64/libz.so.1 (0x00007fed2da04000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fed2d9fe000)
libc.so.6 => /lib64/libc.so.6 (0x00007fed2d838000)
/lib64/ld-linux-x86-64.so.2 (0x00007fed2da3e000)
[acme@quaco perf]$
Meaning it built properly, so in this sytem the disassembler() function
has indeed four args, so we end up with:
[acme@quaco perf]$ grep disassembler /tmp/build/perf/FEATURE-DUMP
feature-disassembler-four-args=1
[acme@quaco perf]$
Can you check the output for
/tmp/build/perf/feature/test-disassembler-four-args.make.output in your
system? And also check what is the prototype for the disassembler()
routine on mageia7?
Here I have:
[acme@quaco perf]$ rpm -q binutils
binutils-2.31.1-25.fc29.x86_64
[acme@quaco perf]$
Perhaps binutils 2.32 changed that prototype again and instead of
falling back to using just one arg we need to use some other number of
args, or even a different type for the N args it now maybe have?
- Arnaldo