Hi,
I already reported this build-error (see [1]).
Today, I had time to look closer to it.
I build with `make -j1` to see more details.
This is with Linux v5.19-rc4-208-g69cb6c6556ad.
[ BUILD-ERROR ]
[ ... ]
clang -Wp,-MD,util/.annotate.o.d -Wp,-MT,util/annotate.o
-Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
-Wformat-y2k -Winit-self -Wmissing-d
eclarations -Wmissing-prototypes -Wno-system-headers
-Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes
-Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat
-Wno-type-limits -Wshadow -DHAVE_SYSCALL_TABLE_SUPPORT
-DHAVE_ARCH_X86_64_SUPPORT -Iarch/x86/include/generated
-DHAVE_PERF_REGS_SUPPORT -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET
-Werror -O3 -fno-omit-frame-pointer -ggdb3 -funwind-tables -Wall
-Wextra -std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-I/home/dileks/src/linux/git/tools/lib/perf/include
-I/home/dileks/src/linux/git/tools/perf/util/include
-I/home/dileks/src/linux/git/tools/perf/arch/x86/include
-I/home/dileks/src/linux/git/tools/include/
-I/home/dileks/src/linux/git/tools/arch/x86/include/uapi
-I/home/dileks/src/linux/git/tools/include/uapi
-I/home/dileks/src/linux/git/tools/arch/x86/include/
-I/home/dileks/src/linux/git/tools/arch/x86/
-I/home/dileks/src/linux/git/tools/perf/util
-I/home/dileks/src/linux/git/tools/perf
-I/home/dileks/src/linux/git/tools/lib/
-DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_PTHREAD_BARRIER
-DHAVE_EVENTFD_SUPPORT -DHAVE_
GET_CURRENT_DIR_NAME -DHAVE_GETTID -DHAVE_FILE_HANDLE
-DHAVE_DWARF_GETLOCATIONS_SUPPORT -DHAVE_GLIBC_SUPPORT
-DHAVE_AIO_SUPPORT -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT
-DHAVE_LIBELF_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT
-DHAVE_GELF_GETNOTE_SUPPORT -DHAVE_ELF_GETSHDRSTRNDX_SUPPORT
-DHAVE_DWARF_SUPPORT -DHAVE_LIBBPF_SUPPORT -
DHAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID -DHAVE_LIBBPF_BPF_PROG_LOAD
-DHAVE_LIBBPF_BPF_OBJECT__NEXT_PROGRAM
-DHAVE_LIBBPF_BPF_OBJECT__NEXT_MAP -DHAVE_LIBBPF_BTF__RAW_D
ATA -DHAVE_LIBBPF_BPF_MAP_CREATE -DHAVE_BPF_PROLOGUE -DHAVE_SDT_EVENT
-DHAVE_JITDUMP -DHAVE_DWARF_UNWIND_SUPPORT -DNO_LIBUNWIND_DEBUG_FRAME
-DHAVE_LIBUNWIND_SUPPORT -D
HAVE_SLANG_SUPPORT -DHAVE_LIBPERL_SUPPORT
-Wno-compound-token-split-by-macro -DHAVE_TIMERFD_SUPPORT
-DHAVE_LIBPYTHON_SUPPORT -DHAVE_LIBBFD_BUILDID_SUPPORT -DHAVE_CPLUS
_DEMANGLE_SUPPORT -DHAVE_LIBBFD_SUPPORT -DHAVE_ZLIB_SUPPORT
-DHAVE_LZMA_SUPPORT -DHAVE_ZSTD_SUPPORT -DHAVE_LIBCAP_SUPPORT
-DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPO
RT -DHAVE_KVM_STAT_SUPPORT -DDISASM_FOUR_ARGS_SIGNATURE
-DHAVE_PERF_READ_VDSO32 -DHAVE_PERF_READ_VDSOX32
-DHAVE_LIBBABELTRACE_SUPPORT -DHAVE_AUXTRACE_SUPPORT -D"BUILD_
STR(s)=#s" -c -o util/annotate.o util/annotate.c
[ ... ]
util/annotate.c:1766:33: error: too few arguments to function call,
expected 4, have 3
(fprintf_ftype) fprintf);
^
/usr/include/dis-asm.h:472:13: note: 'init_disassemble_info' declared here
extern void init_disassemble_info (struct disassemble_info *dinfo, void *stream,
^
1 error generated.
make[4]: *** [/home/dileks/src/linux/git/tools/build/Makefile.build:97:
util/annotate.o] Error 1
[ REPRODUCER ]
LLVM_MVER="14"
##LLVM_TOOLCHAIN_PATH="/usr/lib/llvm-${LLVM_MVER}/bin"
LLVM_TOOLCHAIN_PATH="/opt/llvm/bin"
if [ -d ${LLVM_TOOLCHAIN_PATH} ]; then
export PATH="${LLVM_TOOLCHAIN_PATH}:${PATH}"
fi
PYTHON_VER="3.10"
MAKE="make"
MAKE_OPTS="V=1 -j1 HOSTCC=clang HOSTLD=ld.lld HOSTAR=llvm-ar CC=clang
LD=ld.lld AR=llvm-ar STRIP=llvm-strip"
echo "LLVM MVER ........ $LLVM_MVER"
echo "Path settings .... $PATH"
echo "Python version ... $PYTHON_VER"
echo "make line ........ $MAKE $MAKE_OPTS"
LANG=C LC_ALL=C make -C tools/perf clean 2>&1 | tee ../make-log_perf-clean.txt
LANG=C LC_ALL=C $MAKE $MAKE_OPTS -C tools/perf
PYTHON=python${PYTHON_VER} install-bin 2>&1 | tee
../make-log_perf-python${PYTHON_VER}-install_bin.txt
Attached is the build-log as Gmail might have truncated the lines above.
If you need further information, please let me know.
Thanks.
Regards,
-Sedat-
[1] https://lore.kernel.org/all/CA+icZUXYZiVsj8Bw7Yz+m93-trpVA3omPTUdrwWqHQMnaUdxjw@mail.gmail.com/
On Sun, Jul 3, 2022 at 12:57 PM Sedat Dilek <[email protected]> wrote:
[ ... ]
> util/annotate.c:1766:33: error: too few arguments to function call,
> expected 4, have 3
> (fprintf_ftype) fprintf);
> ^
> /usr/include/dis-asm.h:472:13: note: 'init_disassemble_info' declared here
> extern void init_disassemble_info (struct disassemble_info *dinfo, void *stream,
> ^
> 1 error generated.
> make[4]: *** [/home/dileks/src/linux/git/tools/build/Makefile.build:97:
> util/annotate.o] Error 1
This is with Debian's binutils(-dev) version 2.38.50.20220629-4.
$ dpkg -S /usr/include/dis-asm.h
binutils-dev: /usr/include/dis-asm.h
-Sedat-
On Sun, Jul 3, 2022 at 1:03 PM Sedat Dilek <[email protected]> wrote:
>
> On Sun, Jul 3, 2022 at 12:57 PM Sedat Dilek <[email protected]> wrote:
> [ ... ]
> > util/annotate.c:1766:33: error: too few arguments to function call,
> > expected 4, have 3
> > (fprintf_ftype) fprintf);
> > ^
> > /usr/include/dis-asm.h:472:13: note: 'init_disassemble_info' declared here
> > extern void init_disassemble_info (struct disassemble_info *dinfo, void *stream,
> > ^
> > 1 error generated.
> > make[4]: *** [/home/dileks/src/linux/git/tools/build/Makefile.build:97:
> > util/annotate.o] Error 1
>
> This is with Debian's binutils(-dev) version 2.38.50.20220629-4.
>
> $ dpkg -S /usr/include/dis-asm.h
> binutils-dev: /usr/include/dis-asm.h
>
[ /usr/include/dis-asm.h ]
470 /* Method to initialize a disassemble_info struct. This should be
471 called by all applications creating such a struct. */
472 extern void init_disassemble_info (struct disassemble_info *dinfo,
void *stream,
473 fprintf_ftype fprintf_func,
474 fprintf_styled_ftype
fprintf_styled_func);
-Sedat-
On Sun, Jul 3, 2022 at 1:06 PM Sedat Dilek <[email protected]> wrote:
>
> On Sun, Jul 3, 2022 at 1:03 PM Sedat Dilek <[email protected]> wrote:
> >
> > On Sun, Jul 3, 2022 at 12:57 PM Sedat Dilek <[email protected]> wrote:
> > [ ... ]
> > > util/annotate.c:1766:33: error: too few arguments to function call,
> > > expected 4, have 3
> > > (fprintf_ftype) fprintf);
> > > ^
> > > /usr/include/dis-asm.h:472:13: note: 'init_disassemble_info' declared here
> > > extern void init_disassemble_info (struct disassemble_info *dinfo, void *stream,
> > > ^
> > > 1 error generated.
> > > make[4]: *** [/home/dileks/src/linux/git/tools/build/Makefile.build:97:
> > > util/annotate.o] Error 1
> >
> > This is with Debian's binutils(-dev) version 2.38.50.20220629-4.
> >
> > $ dpkg -S /usr/include/dis-asm.h
> > binutils-dev: /usr/include/dis-asm.h
> >
>
> [ /usr/include/dis-asm.h ]
>
> 470 /* Method to initialize a disassemble_info struct. This should be
> 471 called by all applications creating such a struct. */
> 472 extern void init_disassemble_info (struct disassemble_info *dinfo,
> void *stream,
> 473 fprintf_ftype fprintf_func,
> 474 fprintf_styled_ftype
> fprintf_styled_func);
>
[ CC Andres F. + bpf folks ]
The patch-series from Andres Freund from [1] fixes the issue for me on
Debian/unstable AMD64:
[PATCH v1 0/3] tools: fix compilation failure caused by
init_disassemble_info API changes
[PATCH v1 1/3] tools build: add feature test for init_disassemble_info
API changes
[PATCH v1 2/3] tools: add dis-asm-compat.h to centralize handling of
version differences
[PATCH v1 3/3] tools: Use tools/dis-asm-compat.h to fix compilation
errors with new binutils
Compile-tested only (LLVM-14 x86-64).
link="https://lore.kernel.org/lkml/[email protected]/"
b4 -d am $link
Andres, you have some test-cases how you verified the built perf is OK?
Thanks, Andres.
-Sedat-
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://lore.kernel.org/lkml/CA+icZUVVXq0Mh8=QuopF0tMZyZ0Tn8AiKEZoA3jfP47Q8B=x2A@mail.gmail.com/
On July 3, 2022 8:54:41 AM GMT-03:00, Sedat Dilek <[email protected]> wrote:
>On Sun, Jul 3, 2022 at 1:06 PM Sedat Dilek <[email protected]> wrote:
>>
>> On Sun, Jul 3, 2022 at 1:03 PM Sedat Dilek <[email protected]> wrote:
>> >
>> > On Sun, Jul 3, 2022 at 12:57 PM Sedat Dilek <[email protected]> wrote:
>> > [ ... ]
>> > > util/annotate.c:1766:33: error: too few arguments to function call,
>> > > expected 4, have 3
>> > > (fprintf_ftype) fprintf);
>> > > ^
>> > > /usr/include/dis-asm.h:472:13: note: 'init_disassemble_info' declared here
>> > > extern void init_disassemble_info (struct disassemble_info *dinfo, void *stream,
>> > > ^
>> > > 1 error generated.
>> > > make[4]: *** [/home/dileks/src/linux/git/tools/build/Makefile.build:97:
>> > > util/annotate.o] Error 1
>> >
>> > This is with Debian's binutils(-dev) version 2.38.50.20220629-4.
>> >
>> > $ dpkg -S /usr/include/dis-asm.h
>> > binutils-dev: /usr/include/dis-asm.h
>> >
>>
>> [ /usr/include/dis-asm.h ]
>>
>> 470 /* Method to initialize a disassemble_info struct. This should be
>> 471 called by all applications creating such a struct. */
>> 472 extern void init_disassemble_info (struct disassemble_info *dinfo,
>> void *stream,
>> 473 fprintf_ftype fprintf_func,
>> 474 fprintf_styled_ftype
>> fprintf_styled_func);
>>
>
>[ CC Andres F. + bpf folks ]
>
>The patch-series from Andres Freund from [1] fixes the issue for me on
>Debian/unstable AMD64:
>
>[PATCH v1 0/3] tools: fix compilation failure caused by
>init_disassemble_info API changes
>[PATCH v1 1/3] tools build: add feature test for init_disassemble_info
>API changes
>[PATCH v1 2/3] tools: add dis-asm-compat.h to centralize handling of
>version differences
>[PATCH v1 3/3] tools: Use tools/dis-asm-compat.h to fix compilation
>errors with new binutils
>
>Compile-tested only (LLVM-14 x86-64).
>
>link="https://lore.kernel.org/lkml/[email protected]/"
>b4 -d am $link
>
>Andres, you have some test-cases how you verified the built perf is OK?
That series should be split a bit further, so that the
new features test is in a separate patch, i.e. I don't process bpftool patches, but can process the feature test and the tools/perf part.
Thanks Sedat for drilling deeper, identifying Andres work as a cure, thanks to Andres for that patch kit!
- Arnaldo
>
>Thanks, Andres.
>
>-Sedat-
>
>[1] https://lore.kernel.org/lkml/[email protected]/
>[2] https://lore.kernel.org/lkml/CA+icZUVVXq0Mh8=QuopF0tMZyZ0Tn8AiKEZoA3jfP47Q8B=x2A@mail.gmail.com/
Hi,
On 2022-07-03 13:54:41 +0200, Sedat Dilek wrote:
> Andres, you have some test-cases how you verified the built perf is OK?
I ran an intentionally expensive workload, monitored it with bpftrace, then
took a perf profile. Then annotated the bpf "function" and verified it looked
the same before / after, using a perf built in a container (and thus
compiling).
Similar with bpftool, I dumped a jited program with a bpftool built with /
without the patches (inside the container using nsenter for the version
without the patches, so I could build it, using nsenter -t $pid -m -p) and
compared both the json and non-json output before / after.
V=4; nsenter -t 847325 -m -p /usr/src/linux/tools/bpf/bpftool/bpftool -j -d prog dump jited id 22 > /tmp/22.jit.json.$V; nsenter -t 847325 -m -p /usr/src/linux/tools/bpf/bpftool/bpftool -d prog dump jited id 22 > /tmp/22.jit.txt.$V
and then diffed the results.
bpf_jit_disasm was harder, because bpf_jit_enable = 2 is broken currently. So
I gathered output in a VM from an older kernel, and used bpf_jit_disasm -f ...
before / after the patches.
Greetings,
Andres Freund
Hi,
On 2022-07-03 10:54:45 -0300, Arnaldo Carvalho de Melo wrote:
> That series should be split a bit further, so that the
> new features test is in a separate patch, i.e. I don't process bpftool patches, but can process the feature test and the tools/perf part.
Ok, will split it further. Should I do
1) feature test
2) introduce compat header header
3) use feature test, use header in perf/
4) use feature test, use header in bpf/
Or should 3, 4 be split to separately introduce the feature test and use of
the compat header?
Greetings,
Andres Freund
On July 3, 2022 1:54:48 PM GMT-03:00, Andres Freund <[email protected]> wrote:
>Hi,
>
>On 2022-07-03 10:54:45 -0300, Arnaldo Carvalho de Melo wrote:
>> That series should be split a bit further, so that the
>> new features test is in a separate patch, i.e. I don't process bpftool patches, but can process the feature test and the tools/perf part.
>
>Ok, will split it further. Should I do
>
>1) feature test
>2) introduce compat header header
>3) use feature test, use header in perf/
>4) use feature test, use header in bpf/
>
>Or should 3, 4 be split to separately introduce the feature test and use of
>the compat header?
I think 4 patches are ok,
- Arnaldo
>
>Greetings,
>
>Andres Freund
On Sun, Jul 3, 2022 at 7:47 PM Arnaldo Carvalho de Melo
<[email protected]> wrote:
>
>
>
> On July 3, 2022 1:54:48 PM GMT-03:00, Andres Freund <[email protected]> wrote:
> >Hi,
> >
> >On 2022-07-03 10:54:45 -0300, Arnaldo Carvalho de Melo wrote:
> >> That series should be split a bit further, so that the
> >> new features test is in a separate patch, i.e. I don't process bpftool patches, but can process the feature test and the tools/perf part.
> >
> >Ok, will split it further. Should I do
> >
> >1) feature test
> >2) introduce compat header header
> >3) use feature test, use header in perf/
> >4) use feature test, use header in bpf/
> >
> >Or should 3, 4 be split to separately introduce the feature test and use of
> >the compat header?
>
> I think 4 patches are ok,
>
Andres can you CC me on a new patchset?
Thanks.
-sed@-
On Sun, Jul 3, 2022 at 6:51 PM Andres Freund <[email protected]> wrote:
>
> Hi,
>
> On 2022-07-03 13:54:41 +0200, Sedat Dilek wrote:
> > Andres, you have some test-cases how you verified the built perf is OK?
>
> I ran an intentionally expensive workload, monitored it with bpftrace, then
> took a perf profile. Then annotated the bpf "function" and verified it looked
> the same before / after, using a perf built in a container (and thus
> compiling).
>
>
> Similar with bpftool, I dumped a jited program with a bpftool built with /
> without the patches (inside the container using nsenter for the version
> without the patches, so I could build it, using nsenter -t $pid -m -p) and
> compared both the json and non-json output before / after.
>
> V=4; nsenter -t 847325 -m -p /usr/src/linux/tools/bpf/bpftool/bpftool -j -d prog dump jited id 22 > /tmp/22.jit.json.$V; nsenter -t 847325 -m -p /usr/src/linux/tools/bpf/bpftool/bpftool -d prog dump jited id 22 > /tmp/22.jit.txt.$V
>
> and then diffed the results.
>
>
> bpf_jit_disasm was harder, because bpf_jit_enable = 2 is broken currently. So
> I gathered output in a VM from an older kernel, and used bpf_jit_disasm -f ...
> before / after the patches.
>
My test-case was to build a Linux v5.19-rc4 plus custom patches
including your v1 patchset.
Using my selfmade perf:
$ ~/bin/perf -vv
perf version 5.19.0-rc4
dwarf: [ on ] # HAVE_DWARF_SUPPORT
dwarf_getlocations: [ on ] # HAVE_DWARF_GETLOCATIONS_SUPPORT
glibc: [ on ] # HAVE_GLIBC_SUPPORT
syscall_table: [ on ] # HAVE_SYSCALL_TABLE_SUPPORT
libbfd: [ on ] # HAVE_LIBBFD_SUPPORT
debuginfod: [ OFF ] # HAVE_DEBUGINFOD_SUPPORT
libelf: [ on ] # HAVE_LIBELF_SUPPORT
libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT
numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT
libperl: [ on ] # HAVE_LIBPERL_SUPPORT
libpython: [ on ] # HAVE_LIBPYTHON_SUPPORT
libslang: [ on ] # HAVE_SLANG_SUPPORT
libcrypto: [ on ] # HAVE_LIBCRYPTO_SUPPORT
libunwind: [ on ] # HAVE_LIBUNWIND_SUPPORT
libdw-dwarf-unwind: [ on ] # HAVE_DWARF_SUPPORT
zlib: [ on ] # HAVE_ZLIB_SUPPORT
lzma: [ on ] # HAVE_LZMA_SUPPORT
get_cpuid: [ on ] # HAVE_AUXTRACE_SUPPORT
bpf: [ on ] # HAVE_LIBBPF_SUPPORT
aio: [ on ] # HAVE_AIO_SUPPORT
zstd: [ on ] # HAVE_ZSTD_SUPPORT
libpfm4: [ OFF ] # HAVE_LIBPFM
make-line:
/home/dileks/bin/perf stat make V=1 -j4 LLVM=1 LLVM_IAS=1
PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-1-amd64-clang
14-lto KBUILD_BUILD_HOST=iniza [email protected]
KBUILD_BUILD_TIMESTAMP=2022-07-03 bindeb-pkg
KDEB_PKGVERSION=5.19.0~rc4-1~bookworm+dileks1
Performance counter stats for 'make V=1 -j4 LLVM=1 LLVM_IAS=1
PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-1-amd64-clang14-lto
KBUILD_BUILD_HOST=iniza [email protected]
KBUILD_BUILD_TIMESTAMP=2022-07-03 bindeb-pkg
KDEB_PKGVERSION=5.19.0~rc4-1~bookworm+dileks1':
49180053.86 msec task-clock # 3.371 CPUs
utilized
11647016 context-switches # 236.824 /sec
341509 cpu-migrations # 6.944 /sec
341092829 page-faults # 6.936 K/sec
86858202428205 cycles # 1.766 GHz
63272333662538 stalled-cycles-frontend # 72.85% frontend
cycles idle
45610931269521 stalled-cycles-backend # 52.51% backend
cycles idle
58841762567958 instructions # 0.68 insn per
cycle
# 1.08 stalled
cycles per insn
10469937534492 branches # 212.890 M/sec
558492683589 branch-misses # 5.33% of all
branches
14587.639724247 seconds time elapsed
45568.184531000 seconds user
3656.227306000 seconds sys
Hmmm, it took a bit longer as usual.
But hey:
$ cat /proc/version
Linux version 5.19.0-rc4-1-amd64-clang14-lto
([email protected]@iniza) (dileks clang version 14.0.5
(https://github.com/llvm/llvm-project.git
c12386ae247c0d46e1d513942e322e3a0510b126), LLD 14.0.5)
#1~bookworm+dileks1 SMP PREEMPT_DYNAMIC 2022-07-03
-Sedat-
Hi,
On 2022-07-03 22:40:22 +0200, Sedat Dilek wrote:
> My test-case was to build a Linux v5.19-rc4 plus custom patches
> including your v1 patchset.
> make-line:
>
> /home/dileks/bin/perf stat make V=1 -j4 LLVM=1 LLVM_IAS=1
> PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-1-amd64-clang
> 14-lto KBUILD_BUILD_HOST=iniza [email protected]
> KBUILD_BUILD_TIMESTAMP=2022-07-03 bindeb-pkg
> KDEB_PKGVERSION=5.19.0~rc4-1~bookworm+dileks1
> [...]
> Hmmm, it took a bit longer as usual.
I don't think the patches would affect the performance of this workload - I
don't know the kernel build process well, but I don't see why anything in it
would trigger bpf programs to be disassembled? I guess the additional three
feature tests can take a tiny bit of time, but...
Sent out a new version, did add you as a CC.
Greetings,
Andres Freund