All of lore.kernel.org
 help / color / mirror / Atom feed
* perf tools build broken after v5.1-rc1
@ 2019-04-19 23:32 ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-19 23:32 UTC (permalink / raw)
  To: linux-perf-users, Arnaldo Carvalho de Melo
  Cc: lkml, arcml, Arnd Bergmann, Jiri Olsa, Namhyung Kim

Hi,

When building perf for ARC (v5.1-rc2) I get the following

| In file included from bench/futex-hash.c:26:
| bench/futex.h: In function 'futex_wait':
| bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);

git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
Sync copy of asm-generic/unistd.h with the kernel sources")

The issue is due to hunk below, rightly brought over from commit c8ce48f06503
("asm-generic: Make time32 syscall numbers optional")

+#if defined(__ARCH_WANT_TIME32_SYSCALLS) || __BITS_PER_LONG != 32
 #define __NR_futex 98
-__SC_COMP(__NR_futex, sys_futex, compat_sys_futex)
+__SC_3264(__NR_futex, sys_futex_time32, sys_futex)
+#endif

While __ARCH_WANT_TIME32_SYSCALLS does exist in
arch/arc/include/uapi/asm/unistd.h, but not inside tools, essentially we lack a
copy such as below which were sync'ed by commit above as well.

   tools/arch/arm64/include/uapi/asm/unistd.h
   tools/arch/x86/include/uapi/asm/unistd.h

A quick fix for ARC will be to create our own version but I presume all existing
arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
send out a patch for ARC.

P.S. Why do we need the unistd.h duplication in tools directory, given it could
have used the in-tree unistd headers directly ?

Thx,
-Vineet

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-19 23:32 ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-19 23:32 UTC (permalink / raw)
  To: linux-snps-arc

Hi,

When building perf for ARC (v5.1-rc2) I get the following

| In file included from bench/futex-hash.c:26:
| bench/futex.h: In function 'futex_wait':
| bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);

git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
Sync copy of asm-generic/unistd.h with the kernel sources")

The issue is due to hunk below, rightly brought over from commit c8ce48f06503
("asm-generic: Make time32 syscall numbers optional")

+#if defined(__ARCH_WANT_TIME32_SYSCALLS) || __BITS_PER_LONG != 32
 #define __NR_futex 98
-__SC_COMP(__NR_futex, sys_futex, compat_sys_futex)
+__SC_3264(__NR_futex, sys_futex_time32, sys_futex)
+#endif

While __ARCH_WANT_TIME32_SYSCALLS does exist in
arch/arc/include/uapi/asm/unistd.h, but not inside tools, essentially we lack a
copy such as below which were sync'ed by commit above as well.

   tools/arch/arm64/include/uapi/asm/unistd.h
   tools/arch/x86/include/uapi/asm/unistd.h

A quick fix for ARC will be to create our own version but I presume all existing
arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
send out a patch for ARC.

P.S. Why do we need the unistd.h duplication in tools directory, given it could
have used the in-tree unistd headers directly ?

Thx,
-Vineet

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-19 23:32 ` Vineet Gupta
@ 2019-04-22 15:20   ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-22 15:20 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnaldo Carvalho de Melo, Arnd Bergmann, lkml, linux-perf-users,
	Jiri Olsa, Namhyung Kim, arcml

Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> When building perf for ARC (v5.1-rc2) I get the following
 
> | In file included from bench/futex-hash.c:26:
> | bench/futex.h: In function 'futex_wait':
> | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
 
> git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> Sync copy of asm-generic/unistd.h with the kernel sources")

Humm, I have to check why this:

[perfbuilder@quaco ~]$ podman images | grep ARC
docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
[perfbuilder@quaco ~]$

isn't catching this... :-\

FROM docker.io/fedora:24
MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
ENV CROSS=arc-linux-
ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
RUN wget https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-rc2/${SOURCEFILE}
<SNIP>
COPY rx_and_build.sh /
ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
ENV ARCH=arc
ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
ENV EXTRA_CFLAGS=-matomic

I have to update this to fedora 29 or 30 and get a newer toolchain...
 
> The issue is due to hunk below, rightly brought over from commit c8ce48f06503
> ("asm-generic: Make time32 syscall numbers optional")
 
> +#if defined(__ARCH_WANT_TIME32_SYSCALLS) || __BITS_PER_LONG != 32
>  #define __NR_futex 98
> -__SC_COMP(__NR_futex, sys_futex, compat_sys_futex)
> +__SC_3264(__NR_futex, sys_futex_time32, sys_futex)
> +#endif
 
> While __ARCH_WANT_TIME32_SYSCALLS does exist in
> arch/arc/include/uapi/asm/unistd.h, but not inside tools, essentially we lack a
> copy such as below which were sync'ed by commit above as well.
 
>    tools/arch/arm64/include/uapi/asm/unistd.h
>    tools/arch/x86/include/uapi/asm/unistd.h

So yeah, we need to grab those copies that define something that is used
conditionally by something we have in tools, I'm trying to cook up a
patch grabbing the missing tools/arch/*/include/uapi/asm/unistd.h files,
will they fire a container test build that should cover lots of the
archs.

thanks for the report, will get back here with a report of the results
or else you'll get the patch flying to Ingo for tip/perf/urgent.
 
> A quick fix for ARC will be to create our own version but I presume all existing
> arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
> send out a patch for ARC.
> 
> P.S. Why do we need the unistd.h duplication in tools directory, given it could
> have used the in-tree unistd headers directly ?

I have to write down the explanation and have it in a file, but we can't
use anything in the kernel from outside tools/ to avoid adding a burden
to kernel developers that would then have to make sure that the changes
that they make outside tools/ don't break things living there.

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-22 15:20   ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-22 15:20 UTC (permalink / raw)
  To: linux-snps-arc

Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> When building perf for ARC (v5.1-rc2) I get the following
 
> | In file included from bench/futex-hash.c:26:
> | bench/futex.h: In function 'futex_wait':
> | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
 
> git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> Sync copy of asm-generic/unistd.h with the kernel sources")

Humm, I have to check why this:

[perfbuilder at quaco ~]$ podman images | grep ARC
docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
[perfbuilder at quaco ~]$

isn't catching this... :-\

FROM docker.io/fedora:24
MAINTAINER Arnaldo Carvalho de Melo <acme at kernel.org>
ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
ENV CROSS=arc-linux-
ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
RUN wget https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-rc2/${SOURCEFILE}
<SNIP>
COPY rx_and_build.sh /
ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
ENV ARCH=arc
ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
ENV EXTRA_CFLAGS=-matomic

I have to update this to fedora 29 or 30 and get a newer toolchain...
 
> The issue is due to hunk below, rightly brought over from commit c8ce48f06503
> ("asm-generic: Make time32 syscall numbers optional")
 
> +#if defined(__ARCH_WANT_TIME32_SYSCALLS) || __BITS_PER_LONG != 32
>  #define __NR_futex 98
> -__SC_COMP(__NR_futex, sys_futex, compat_sys_futex)
> +__SC_3264(__NR_futex, sys_futex_time32, sys_futex)
> +#endif
 
> While __ARCH_WANT_TIME32_SYSCALLS does exist in
> arch/arc/include/uapi/asm/unistd.h, but not inside tools, essentially we lack a
> copy such as below which were sync'ed by commit above as well.
 
>    tools/arch/arm64/include/uapi/asm/unistd.h
>    tools/arch/x86/include/uapi/asm/unistd.h

So yeah, we need to grab those copies that define something that is used
conditionally by something we have in tools, I'm trying to cook up a
patch grabbing the missing tools/arch/*/include/uapi/asm/unistd.h files,
will they fire a container test build that should cover lots of the
archs.

thanks for the report, will get back here with a report of the results
or else you'll get the patch flying to Ingo for tip/perf/urgent.
 
> A quick fix for ARC will be to create our own version but I presume all existing
> arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
> send out a patch for ARC.
> 
> P.S. Why do we need the unistd.h duplication in tools directory, given it could
> have used the in-tree unistd headers directly ?

I have to write down the explanation and have it in a file, but we can't
use anything in the kernel from outside tools/ to avoid adding a burden
to kernel developers that would then have to make sure that the changes
that they make outside tools/ don't break things living there.

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-22 15:20   ` Arnaldo Carvalho de Melo
@ 2019-04-25 21:48     ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-25 21:48 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: linux-perf-users, Arnaldo Carvalho de Melo, lkml, arcml,
	Arnd Bergmann, Jiri Olsa, Namhyung Kim

Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> > When building perf for ARC (v5.1-rc2) I get the following
>  
> > | In file included from bench/futex-hash.c:26:
> > | bench/futex.h: In function 'futex_wait':
> > | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
>  
> > git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> > Sync copy of asm-generic/unistd.h with the kernel sources")
> 
> Humm, I have to check why this:
> 
> [perfbuilder@quaco ~]$ podman images | grep ARC
> docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> [perfbuilder@quaco ~]$
> 
> isn't catching this... :-\
> 
> FROM docker.io/fedora:24
> MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> ENV CROSS=arc-linux-
> ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> RUN wget https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-rc2/${SOURCEFILE}
> <SNIP>
> COPY rx_and_build.sh /
> ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> ENV ARCH=arc
> ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> ENV EXTRA_CFLAGS=-matomic

So, now I have a libnuma crossbuilt in this container that allows me to
build a ARC perf binary linked with zlib and numactl-devel, but only
after I applied the fix below.

Can you please provide the feature detection header in the build? I.e.
what I have with my ARC cross build container right now, after applying
the patch below is:

[perfbuilder@60d5802468f6 perf]$ make $EXTRA_MAKE_ARGS ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE EXTRA_CFLAGS="$EXTRA_CFLAGS" -C /git/perf/tools/perf O=/tmp/build/perf
make: Entering directory '/git/perf/tools/perf'
  BUILD:   Doing 'make -j8' parallel build
sh: line 0: command: -c: invalid option
command: usage: command [-pVv] command [arg ...]

Auto-detecting system features:
...                         dwarf: [ OFF ]
...            dwarf_getlocations: [ OFF ]
...                         glibc: [ on  ]
...                          gtk2: [ OFF ]
...                      libaudit: [ OFF ]
...                        libbfd: [ OFF ]
...                        libelf: [ OFF ]
...                       libnuma: [ on  ]
...        numa_num_possible_cpus: [ on  ]
...                       libperl: [ OFF ]
...                     libpython: [ OFF ]
...                      libslang: [ OFF ]
...                     libcrypto: [ OFF ]
...                     libunwind: [ OFF ]
...            libdw-dwarf-unwind: [ OFF ]
...                          zlib: [ OFF ]
...                          lzma: [ OFF ]
...                     get_cpuid: [ OFF ]
...                           bpf: [ on  ]
...                        libaio: [ OFF ]
...        disassembler-four-args: [ OFF ]

Makefile.config:339: No libelf found. Disables 'probe' tool, jvmti and BPF support in 'perf record'. Please install libelf-dev, libelf-devel or elfutils-libelf-devel
Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:548: Disabling post unwind, no support found.
Makefile.config:601: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev
Makefile.config:613: No libcrypto.h found, disables jitted code injection, please install openssl-devel or libssl-dev
Makefile.config:628: slang not found, disables TUI support. Please install slang-devel, libslang-dev or libslang2-dev
Makefile.config:642: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev
Makefile.config:669: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev
Makefile.config:696: No python interpreter was found: disables Python support - please install python-devel/python-dev
Makefile.config:785: No liblzma found, disables xz kernel module decompression, please install xz-devel/liblzma-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
make: Leaving directory '/git/perf/tools/perf'
[perfbuilder@60d5802468f6 perf]$ export
declare -x ARCH="arc"
declare -x CROSS="arc-linux-"
declare -x CROSS_COMPILE="/arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-"
declare -x DISTTAG="f30container"
declare -x EXTRA_CFLAGS="-matomic"
declare -x EXTRA_MAKE_ARGS="NO_LIBBPF=1"
declare -x FBR="f30"
declare -x FGC="f30"
declare -x NUMACTL_SOURCEFILE="github.com-numactl-numactl-archive-master-2019-04-25.zip"
declare -x PATH="/home/perfbuilder/.local/bin:/home/perfbuilder/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
declare -x SOURCEFILE="arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install.tar.gz"
declare -x TOOLCHAIN="arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install"
declare -x container="podman"
[perfbuilder@60d5802468f6 perf]$ 

commit dd617baf28925cf72fce309232ad9178452e75ab
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Apr 25 18:36:51 2019 -0300

    perf bench numa: Add define for RUSAGE_THREAD if not present
    
    While cross building perf to the ARC architecture on a fedora 30 host,
    we were failing with:
    
          CC       /tmp/build/perf/bench/numa.o
      bench/numa.c: In function ‘worker_thread’:
      bench/numa.c:1261:12: error: ‘RUSAGE_THREAD’ undeclared (first use in this function); did you mean ‘SIGEV_THREAD’?
        getrusage(RUSAGE_THREAD, &rusage);
                  ^~~~~~~~~~~~~
                  SIGEV_THREAD
      bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in
    
    [perfbuilder@60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1
    arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225
    [perfbuilder@60d5802468f6 perf]$
    
    Trying to reproduce a report by Vineet, I noticed that, with just
    cross-built zlib and numactl libraries, I ended up with the above
    failure.
    
    So, since RUSAGE_THREAD is available as a define, check for that and
    numactl libraries, I ended up with the above failure.
    
    So, since RUSAGE_THREAD is available as a define in the system headers,
    check if it is defined in the 'perf bench numa' sources and define it if
    not.
    
    Now it builds and I have to figure out if the problem reported by Vineet
    only takes place if we have libelf or some other library available.
    
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: linux-snps-arc@lists.infradead.org
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
    Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0amk@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index 98ad783efc69..a7784554a80d 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -39,6 +39,10 @@
 #include <numa.h>
 #include <numaif.h>
 
+#ifndef RUSAGE_THREAD
+# define RUSAGE_THREAD 1
+#endif
+
 /*
  * Regular printout to the terminal, supressed if -q is specified:
  */

^ permalink raw reply related	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-25 21:48     ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-25 21:48 UTC (permalink / raw)
  To: linux-snps-arc

Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> > When building perf for ARC (v5.1-rc2) I get the following
>  
> > | In file included from bench/futex-hash.c:26:
> > | bench/futex.h: In function 'futex_wait':
> > | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
>  
> > git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> > Sync copy of asm-generic/unistd.h with the kernel sources")
> 
> Humm, I have to check why this:
> 
> [perfbuilder at quaco ~]$ podman images | grep ARC
> docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> [perfbuilder at quaco ~]$
> 
> isn't catching this... :-\
> 
> FROM docker.io/fedora:24
> MAINTAINER Arnaldo Carvalho de Melo <acme at kernel.org>
> ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> ENV CROSS=arc-linux-
> ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> RUN wget https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-rc2/${SOURCEFILE}
> <SNIP>
> COPY rx_and_build.sh /
> ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> ENV ARCH=arc
> ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> ENV EXTRA_CFLAGS=-matomic

So, now I have a libnuma crossbuilt in this container that allows me to
build a ARC perf binary linked with zlib and numactl-devel, but only
after I applied the fix below.

Can you please provide the feature detection header in the build? I.e.
what I have with my ARC cross build container right now, after applying
the patch below is:

[perfbuilder at 60d5802468f6 perf]$ make $EXTRA_MAKE_ARGS ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE EXTRA_CFLAGS="$EXTRA_CFLAGS" -C /git/perf/tools/perf O=/tmp/build/perf
make: Entering directory '/git/perf/tools/perf'
  BUILD:   Doing 'make -j8' parallel build
sh: line 0: command: -c: invalid option
command: usage: command [-pVv] command [arg ...]

Auto-detecting system features:
...                         dwarf: [ OFF ]
...            dwarf_getlocations: [ OFF ]
...                         glibc: [ on  ]
...                          gtk2: [ OFF ]
...                      libaudit: [ OFF ]
...                        libbfd: [ OFF ]
...                        libelf: [ OFF ]
...                       libnuma: [ on  ]
...        numa_num_possible_cpus: [ on  ]
...                       libperl: [ OFF ]
...                     libpython: [ OFF ]
...                      libslang: [ OFF ]
...                     libcrypto: [ OFF ]
...                     libunwind: [ OFF ]
...            libdw-dwarf-unwind: [ OFF ]
...                          zlib: [ OFF ]
...                          lzma: [ OFF ]
...                     get_cpuid: [ OFF ]
...                           bpf: [ on  ]
...                        libaio: [ OFF ]
...        disassembler-four-args: [ OFF ]

Makefile.config:339: No libelf found. Disables 'probe' tool, jvmti and BPF support in 'perf record'. Please install libelf-dev, libelf-devel or elfutils-libelf-devel
Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:548: Disabling post unwind, no support found.
Makefile.config:601: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev
Makefile.config:613: No libcrypto.h found, disables jitted code injection, please install openssl-devel or libssl-dev
Makefile.config:628: slang not found, disables TUI support. Please install slang-devel, libslang-dev or libslang2-dev
Makefile.config:642: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev
Makefile.config:669: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev
Makefile.config:696: No python interpreter was found: disables Python support - please install python-devel/python-dev
Makefile.config:785: No liblzma found, disables xz kernel module decompression, please install xz-devel/liblzma-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
make: Leaving directory '/git/perf/tools/perf'
[perfbuilder at 60d5802468f6 perf]$ export
declare -x ARCH="arc"
declare -x CROSS="arc-linux-"
declare -x CROSS_COMPILE="/arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-"
declare -x DISTTAG="f30container"
declare -x EXTRA_CFLAGS="-matomic"
declare -x EXTRA_MAKE_ARGS="NO_LIBBPF=1"
declare -x FBR="f30"
declare -x FGC="f30"
declare -x NUMACTL_SOURCEFILE="github.com-numactl-numactl-archive-master-2019-04-25.zip"
declare -x PATH="/home/perfbuilder/.local/bin:/home/perfbuilder/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
declare -x SOURCEFILE="arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install.tar.gz"
declare -x TOOLCHAIN="arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install"
declare -x container="podman"
[perfbuilder at 60d5802468f6 perf]$ 

commit dd617baf28925cf72fce309232ad9178452e75ab
Author: Arnaldo Carvalho de Melo <acme at redhat.com>
Date:   Thu Apr 25 18:36:51 2019 -0300

    perf bench numa: Add define for RUSAGE_THREAD if not present
    
    While cross building perf to the ARC architecture on a fedora 30 host,
    we were failing with:
    
          CC       /tmp/build/perf/bench/numa.o
      bench/numa.c: In function ?worker_thread?:
      bench/numa.c:1261:12: error: ?RUSAGE_THREAD? undeclared (first use in this function); did you mean ?SIGEV_THREAD??
        getrusage(RUSAGE_THREAD, &rusage);
                  ^~~~~~~~~~~~~
                  SIGEV_THREAD
      bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in
    
    [perfbuilder at 60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1
    arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225
    [perfbuilder at 60d5802468f6 perf]$
    
    Trying to reproduce a report by Vineet, I noticed that, with just
    cross-built zlib and numactl libraries, I ended up with the above
    failure.
    
    So, since RUSAGE_THREAD is available as a define, check for that and
    numactl libraries, I ended up with the above failure.
    
    So, since RUSAGE_THREAD is available as a define in the system headers,
    check if it is defined in the 'perf bench numa' sources and define it if
    not.
    
    Now it builds and I have to figure out if the problem reported by Vineet
    only takes place if we have libelf or some other library available.
    
    Cc: Arnd Bergmann <arnd at arndb.de>
    Cc: Jiri Olsa <jolsa at kernel.org>
    Cc: linux-snps-arc at lists.infradead.org
    Cc: Namhyung Kim <namhyung at kernel.org>
    Cc: Vineet Gupta <Vineet.Gupta1 at synopsys.com>
    Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0amk at git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme at redhat.com>

diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index 98ad783efc69..a7784554a80d 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -39,6 +39,10 @@
 #include <numa.h>
 #include <numaif.h>
 
+#ifndef RUSAGE_THREAD
+# define RUSAGE_THREAD 1
+#endif
+
 /*
  * Regular printout to the terminal, supressed if -q is specified:
  */

^ permalink raw reply related	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-25 21:48     ` Arnaldo Carvalho de Melo
@ 2019-04-26 19:28       ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-26 19:28 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: linux-perf-users, Arnaldo Carvalho de Melo, lkml, arcml,
	Arnd Bergmann, Jiri Olsa, Namhyung Kim

Em Thu, Apr 25, 2019 at 06:48:00PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> > > When building perf for ARC (v5.1-rc2) I get the following
> >  
> > > | In file included from bench/futex-hash.c:26:
> > > | bench/futex.h: In function 'futex_wait':
> > > | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
> >  
> > > git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> > > Sync copy of asm-generic/unistd.h with the kernel sources")
> > 
> > Humm, I have to check why this:
> > 
> > [perfbuilder@quaco ~]$ podman images | grep ARC
> > docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> > [perfbuilder@quaco ~]$
> > 
> > isn't catching this... :-\
> > 
> > FROM docker.io/fedora:24
> > MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> > ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> > ENV CROSS=arc-linux-
> > ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> > RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> > RUN wget https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-rc2/${SOURCEFILE}
> > <SNIP>
> > COPY rx_and_build.sh /
> > ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> > ENV ARCH=arc
> > ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> > ENV EXTRA_CFLAGS=-matomic
> 
> So, now I have a libnuma crossbuilt in this container that allows me to
> build a ARC perf binary linked with zlib and numactl-devel, but only
> after I applied the fix below.
> 
> Can you please provide the feature detection header in the build? I.e.
> what I have with my ARC cross build container right now, after applying
> the patch below is:

So, switched from the uCLibc build system to the glibc based one, so
that I could get elfutils building (it needs argp that isn't available
with uCLibc) I have it reproduced, see below, now I'm testing with the
fix, which is to grab the unistd.h files you noticed missing for the
arches that are present in tools/arch/, will post results soon

[perfbuilder@f1798ef8e433 perf]$ make $EXTRA_MAKE_ARGS ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE EXTRA_CFLAGS="$EXTRA_CFLAGS" -C /git/perf/tools/perf O=/tmp/build/perf
make: Entering directory '/git/perf/tools/perf'
  BUILD:   Doing 'make -j8' parallel build
  HOSTCC   /tmp/build/perf/fixdep.o
  HOSTLD   /tmp/build/perf/fixdep-in.o
  LINK     /tmp/build/perf/fixdep
sh: line 0: command: -c: invalid option
command: usage: command [-pVv] command [arg ...]

Auto-detecting system features:
...                         dwarf: [ on  ]
...            dwarf_getlocations: [ on  ]
...                         glibc: [ on  ]
...                          gtk2: [ OFF ]
...                      libaudit: [ OFF ]
...                        libbfd: [ OFF ]
...                        libelf: [ on  ]
...                       libnuma: [ on  ]
...        numa_num_possible_cpus: [ on  ]
...                       libperl: [ OFF ]
...                     libpython: [ OFF ]
...                      libslang: [ OFF ]
...                     libcrypto: [ OFF ]
...                     libunwind: [ OFF ]
...            libdw-dwarf-unwind: [ on  ]
...                          zlib: [ on  ]
...                          lzma: [ OFF ]
...                     get_cpuid: [ OFF ]
...                           bpf: [ on  ]
...                        libaio: [ on  ]
...        disassembler-four-args: [ OFF ]

Makefile.config:441: DWARF register mappings have not been defined for architecture arc, DWARF support disabled
Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:548: Disabling post unwind, no support found.
Makefile.config:601: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev
Makefile.config:613: No libcrypto.h found, disables jitted code injection, please install openssl-devel or libssl-dev
Makefile.config:628: slang not found, disables TUI support. Please install slang-devel, libslang-dev or libslang2-dev
Makefile.config:642: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev
Makefile.config:669: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev
Makefile.config:696: No python interpreter was found: disables Python support - please install python-devel/python-dev
Makefile.config:754: No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static/libiberty-dev to gain symbol demangling
Makefile.config:785: No liblzma found, disables xz kernel module decompression, please install xz-devel/liblzma-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
Makefile.config:897: No openjdk development package found, please install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
  GEN      /tmp/build/perf/common-cmds.h
  CC       /tmp/build/perf/exec-cmd.o
  CC       /tmp/build/perf/help.o
  MKDIR    /tmp/build/perf/fd/
  CC       /tmp/build/perf/fd/array.o
  MKDIR    /tmp/build/perf/fs/
  CC       /tmp/build/perf/event-parse.o
  CC       /tmp/build/perf/pager.o
  LD       /tmp/build/perf/fd/libapi-in.o
  CC       /tmp/build/perf/cpu.o
  MKDIR    /tmp/build/perf/fs/
  CC       /tmp/build/perf/fs/fs.o
  CC       /tmp/build/perf/debug.o
  CC       /tmp/build/perf/fs/tracing_path.o
  CC       /tmp/build/perf/event-plugin.o
  CC       /tmp/build/perf/parse-options.o
  CC       /tmp/build/perf/str_error_r.o
  CC       /tmp/build/perf/trace-seq.o
  CC       /tmp/build/perf/run-command.o
  LD       /tmp/build/perf/fs/libapi-in.o
  CC       /tmp/build/perf/parse-filter.o
  LD       /tmp/build/perf/libapi-in.o
  AR       /tmp/build/perf/libapi.a
  CC       /tmp/build/perf/sigchain.o
  CC       /tmp/build/perf/parse-utils.o
  CC       /tmp/build/perf/kbuffer-parse.o
  CC       /tmp/build/perf/tep_strerror.o
  CC       /tmp/build/perf/subcmd-config.o
  CC       /tmp/build/perf/event-parse-api.o
  MKDIR    /tmp/build/perf/pmu-events/
  MKDIR    /tmp/build/perf/pmu-events/
  LD       /tmp/build/perf/libsubcmd-in.o
  HOSTCC   /tmp/build/perf/pmu-events/json.o
  HOSTCC   /tmp/build/perf/pmu-events/jsmn.o
  LD       /tmp/build/perf/libtraceevent-in.o
  LINK     /tmp/build/perf/libtraceevent.a
  AR       /tmp/build/perf/libsubcmd.a
  MKDIR    /tmp/build/perf/pmu-events/
  HOSTCC   /tmp/build/perf/pmu-events/jevents.o
  CC       /tmp/build/perf/plugin_kvm.o
  CC       /tmp/build/perf/plugin_kmem.o
  CC       /tmp/build/perf/plugin_jbd2.o
  CC       /tmp/build/perf/plugin_hrtimer.o
  CC       /tmp/build/perf/plugin_mac80211.o
  HOSTLD   /tmp/build/perf/pmu-events/jevents-in.o
  CC       /tmp/build/perf/plugin_sched_switch.o
  LD       /tmp/build/perf/plugin_kmem-in.o
  LD       /tmp/build/perf/plugin_jbd2-in.o
  LD       /tmp/build/perf/plugin_mac80211-in.o
  LD       /tmp/build/perf/plugin_hrtimer-in.o
  LINK     /tmp/build/perf/pmu-events/jevents
  LD       /tmp/build/perf/plugin_kvm-in.o
  CC       /tmp/build/perf/plugin_xen.o
  CC       /tmp/build/perf/plugin_function.o
  CC       /tmp/build/perf/plugin_scsi.o
  PERF_VERSION = 5.1.0-rc6
  CC       /tmp/build/perf/plugin_cfg80211.o
  GEN      perf-archive
  GEN      perf-with-kcore
  LD       /tmp/build/perf/plugin_sched_switch-in.o
  GEN      /tmp/build/perf/pmu-events/pmu-events.c
  LINK     /tmp/build/perf/plugin_jbd2.so
  LINK     /tmp/build/perf/plugin_hrtimer.so
  CC       /tmp/build/perf/pmu-events/pmu-events.o
  LD       /tmp/build/perf/plugin_xen-in.o
  LD       /tmp/build/perf/plugin_cfg80211-in.o
  LD       /tmp/build/perf/plugin_function-in.o
  LD       /tmp/build/perf/plugin_scsi-in.o
  LINK     /tmp/build/perf/plugin_kmem.so
  LINK     /tmp/build/perf/plugin_kvm.so
  LINK     /tmp/build/perf/plugin_mac80211.so
  LINK     /tmp/build/perf/plugin_sched_switch.so
  LINK     /tmp/build/perf/plugin_function.so
  LINK     /tmp/build/perf/plugin_xen.so
  LD       /tmp/build/perf/pmu-events/pmu-events-in.o
  LINK     /tmp/build/perf/plugin_scsi.so
  LINK     /tmp/build/perf/plugin_cfg80211.so
  GEN      /tmp/build/perf/libtraceevent-dynamic-list
  LD       /tmp/build/perf/libperf-in.o
  CC       /tmp/build/perf/builtin-config.o
  CC       /tmp/build/perf/builtin-bench.o
  CC       /tmp/build/perf/builtin-annotate.o
  CC       /tmp/build/perf/builtin-diff.o
  CC       /tmp/build/perf/builtin-ftrace.o
  CC       /tmp/build/perf/builtin-evlist.o
  CC       /tmp/build/perf/builtin-help.o
  CC       /tmp/build/perf/builtin-sched.o
  CC       /tmp/build/perf/builtin-buildid-list.o
  CC       /tmp/build/perf/builtin-buildid-cache.o
  CC       /tmp/build/perf/builtin-kallsyms.o
  CC       /tmp/build/perf/builtin-list.o
  CC       /tmp/build/perf/builtin-record.o
  CC       /tmp/build/perf/builtin-report.o
  CC       /tmp/build/perf/builtin-stat.o
  CC       /tmp/build/perf/builtin-timechart.o
  CC       /tmp/build/perf/builtin-top.o
  CC       /tmp/build/perf/builtin-script.o
  CC       /tmp/build/perf/builtin-kmem.o
  CC       /tmp/build/perf/builtin-lock.o
  CC       /tmp/build/perf/builtin-kvm.o
  CC       /tmp/build/perf/builtin-inject.o
  CC       /tmp/build/perf/builtin-mem.o
  CC       /tmp/build/perf/builtin-data.o
  CC       /tmp/build/perf/builtin-version.o
  CC       /tmp/build/perf/builtin-probe.o
  CC       /tmp/build/perf/builtin-c2c.o
  MKDIR    /tmp/build/perf/bench/
  MKDIR    /tmp/build/perf/tests/
  CC       /tmp/build/perf/bench/sched-messaging.o
  MKDIR    /tmp/build/perf/bench/
  CC       /tmp/build/perf/tests/builtin-test.o
  CC       /tmp/build/perf/bench/sched-pipe.o
  CC       /tmp/build/perf/bench/mem-functions.o
  CC       /tmp/build/perf/bench/futex-hash.o
  CC       /tmp/build/perf/bench/futex-wake.o
In file included from bench/futex-hash.c:26:
bench/futex.h: In function ‘futex_wait’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:46:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h:37:10: note: each undeclared identifier is reported only once for each function it appears in
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:46:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ‘futex_wake’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:56:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_WAKE, nr_wake, NULL, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ‘futex_lock_pi’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:65:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_LOCK_PI, 0, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ‘futex_unlock_pi’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:74:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_UNLOCK_PI, 0, NULL, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ‘futex_cmp_requeue’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:86:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_CMP_REQUEUE, nr_wake, nr_requeue, uaddr2,
         ^~~~~
bench/futex.h: In function ‘futex_wait’:
bench/futex.h:47:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
mv: cannot stat '/tmp/build/perf/bench/.futex-hash.o.tmp': No such file or directory
make[4]: *** [/git/perf/tools/build/Makefile.build:96: /tmp/build/perf/bench/futex-hash.o] Error 1
make[4]: *** Waiting for unfinished jobs....
  MKDIR    /tmp/build/perf/tests/
  MKDIR    /tmp/build/perf/arch/
  MKDIR    /tmp/build/perf/util/
  CC       /tmp/build/perf/tests/parse-events.o
  CC       /tmp/build/perf/util/annotate.o
  CC       /tmp/build/perf/arch/common.o
In file included from bench/futex-wake.c:24:
bench/futex.h: In function ‘futex_wait’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:46:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h:37:10: note: each undeclared identifier is reported only once for each function it appears in
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:46:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ‘futex_wake’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:56:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_WAKE, nr_wake, NULL, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ‘futex_lock_pi’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:65:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_LOCK_PI, 0, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ‘futex_unlock_pi’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:74:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_UNLOCK_PI, 0, NULL, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ‘futex_cmp_requeue’:
bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:86:9: note: in expansion of macro ‘futex’
  return futex(uaddr, FUTEX_CMP_REQUEUE, nr_wake, nr_requeue, uaddr2,
         ^~~~~
bench/futex.h: In function ‘futex_wait’:
bench/futex.h:47:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
bench/futex.h: In function ‘futex_wake’:
bench/futex.h:57:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
  MKDIR    /tmp/build/perf/util/
mv: cannot stat '/tmp/build/perf/bench/.futex-wake.o.tmp': No such file or directory
make[4]: *** [/git/perf/tools/build/Makefile.build:96: /tmp/build/perf/bench/futex-wake.o] Error 1
make[3]: *** [/git/perf/tools/build/Makefile.build:139: bench] Error 2
make[3]: *** Waiting for unfinished jobs....
  CC       /tmp/build/perf/util/block-range.o
  CC       /tmp/build/perf/util/build-id.o
  MKDIR    /tmp/build/perf/ui/
  CC       /tmp/build/perf/ui/setup.o
  CC       /tmp/build/perf/util/config.o
  MKDIR    /tmp/build/perf/ui/
  MKDIR    /tmp/build/perf/arch/arc/
  CC       /tmp/build/perf/ui/progress.o
  CC       /tmp/build/perf/ui/helpline.o
  LD       /tmp/build/perf/arch/arc/perf-in.o
  LD       /tmp/build/perf/arch/perf-in.o
  CC       /tmp/build/perf/ui/util.o
  CC       /tmp/build/perf/ui/hist.o
  CC       /tmp/build/perf/tests/dso-data.o
  CC       /tmp/build/perf/util/ctype.o
  MKDIR    /tmp/build/perf/ui/stdio/
  CC       /tmp/build/perf/ui/stdio/hist.o
  CC       /tmp/build/perf/tests/attr.o
  CC       /tmp/build/perf/tests/vmlinux-kallsyms.o
  CC       /tmp/build/perf/util/db-export.o
  CC       /tmp/build/perf/tests/openat-syscall.o
  CC       /tmp/build/perf/tests/openat-syscall-all-cpus.o
  CC       /tmp/build/perf/tests/openat-syscall-tp-fields.o
  CC       /tmp/build/perf/util/env.o
  CC       /tmp/build/perf/util/event.o
  CC       /tmp/build/perf/util/evlist.o
  CC       /tmp/build/perf/tests/mmap-basic.o
  CC       /tmp/build/perf/util/evsel.o
  CC       /tmp/build/perf/util/evsel_fprintf.o
  CC       /tmp/build/perf/util/find_bit.o
  CC       /tmp/build/perf/util/get_current_dir_name.o
  CC       /tmp/build/perf/util/kallsyms.o
  CC       /tmp/build/perf/util/levenshtein.o
  CC       /tmp/build/perf/tests/perf-record.o
  CC       /tmp/build/perf/util/llvm-utils.o
  CC       /tmp/build/perf/tests/evsel-roundtrip-name.o
  CC       /tmp/build/perf/tests/evsel-tp-sched.o
  LD       /tmp/build/perf/ui/perf-in.o
  CC       /tmp/build/perf/tests/fdarray.o
  CC       /tmp/build/perf/util/mmap.o


^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-26 19:28       ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-26 19:28 UTC (permalink / raw)
  To: linux-snps-arc

Em Thu, Apr 25, 2019 at 06:48:00PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> > > When building perf for ARC (v5.1-rc2) I get the following
> >  
> > > | In file included from bench/futex-hash.c:26:
> > > | bench/futex.h: In function 'futex_wait':
> > > | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
> >  
> > > git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> > > Sync copy of asm-generic/unistd.h with the kernel sources")
> > 
> > Humm, I have to check why this:
> > 
> > [perfbuilder at quaco ~]$ podman images | grep ARC
> > docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> > [perfbuilder at quaco ~]$
> > 
> > isn't catching this... :-\
> > 
> > FROM docker.io/fedora:24
> > MAINTAINER Arnaldo Carvalho de Melo <acme at kernel.org>
> > ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> > ENV CROSS=arc-linux-
> > ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> > RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> > RUN wget https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-rc2/${SOURCEFILE}
> > <SNIP>
> > COPY rx_and_build.sh /
> > ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> > ENV ARCH=arc
> > ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> > ENV EXTRA_CFLAGS=-matomic
> 
> So, now I have a libnuma crossbuilt in this container that allows me to
> build a ARC perf binary linked with zlib and numactl-devel, but only
> after I applied the fix below.
> 
> Can you please provide the feature detection header in the build? I.e.
> what I have with my ARC cross build container right now, after applying
> the patch below is:

So, switched from the uCLibc build system to the glibc based one, so
that I could get elfutils building (it needs argp that isn't available
with uCLibc) I have it reproduced, see below, now I'm testing with the
fix, which is to grab the unistd.h files you noticed missing for the
arches that are present in tools/arch/, will post results soon

[perfbuilder at f1798ef8e433 perf]$ make $EXTRA_MAKE_ARGS ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE EXTRA_CFLAGS="$EXTRA_CFLAGS" -C /git/perf/tools/perf O=/tmp/build/perf
make: Entering directory '/git/perf/tools/perf'
  BUILD:   Doing 'make -j8' parallel build
  HOSTCC   /tmp/build/perf/fixdep.o
  HOSTLD   /tmp/build/perf/fixdep-in.o
  LINK     /tmp/build/perf/fixdep
sh: line 0: command: -c: invalid option
command: usage: command [-pVv] command [arg ...]

Auto-detecting system features:
...                         dwarf: [ on  ]
...            dwarf_getlocations: [ on  ]
...                         glibc: [ on  ]
...                          gtk2: [ OFF ]
...                      libaudit: [ OFF ]
...                        libbfd: [ OFF ]
...                        libelf: [ on  ]
...                       libnuma: [ on  ]
...        numa_num_possible_cpus: [ on  ]
...                       libperl: [ OFF ]
...                     libpython: [ OFF ]
...                      libslang: [ OFF ]
...                     libcrypto: [ OFF ]
...                     libunwind: [ OFF ]
...            libdw-dwarf-unwind: [ on  ]
...                          zlib: [ on  ]
...                          lzma: [ OFF ]
...                     get_cpuid: [ OFF ]
...                           bpf: [ on  ]
...                        libaio: [ on  ]
...        disassembler-four-args: [ OFF ]

Makefile.config:441: DWARF register mappings have not been defined for architecture arc, DWARF support disabled
Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:548: Disabling post unwind, no support found.
Makefile.config:601: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev
Makefile.config:613: No libcrypto.h found, disables jitted code injection, please install openssl-devel or libssl-dev
Makefile.config:628: slang not found, disables TUI support. Please install slang-devel, libslang-dev or libslang2-dev
Makefile.config:642: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev
Makefile.config:669: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev
Makefile.config:696: No python interpreter was found: disables Python support - please install python-devel/python-dev
Makefile.config:754: No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static/libiberty-dev to gain symbol demangling
Makefile.config:785: No liblzma found, disables xz kernel module decompression, please install xz-devel/liblzma-dev
Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
Makefile.config:897: No openjdk development package found, please install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
  GEN      /tmp/build/perf/common-cmds.h
  CC       /tmp/build/perf/exec-cmd.o
  CC       /tmp/build/perf/help.o
  MKDIR    /tmp/build/perf/fd/
  CC       /tmp/build/perf/fd/array.o
  MKDIR    /tmp/build/perf/fs/
  CC       /tmp/build/perf/event-parse.o
  CC       /tmp/build/perf/pager.o
  LD       /tmp/build/perf/fd/libapi-in.o
  CC       /tmp/build/perf/cpu.o
  MKDIR    /tmp/build/perf/fs/
  CC       /tmp/build/perf/fs/fs.o
  CC       /tmp/build/perf/debug.o
  CC       /tmp/build/perf/fs/tracing_path.o
  CC       /tmp/build/perf/event-plugin.o
  CC       /tmp/build/perf/parse-options.o
  CC       /tmp/build/perf/str_error_r.o
  CC       /tmp/build/perf/trace-seq.o
  CC       /tmp/build/perf/run-command.o
  LD       /tmp/build/perf/fs/libapi-in.o
  CC       /tmp/build/perf/parse-filter.o
  LD       /tmp/build/perf/libapi-in.o
  AR       /tmp/build/perf/libapi.a
  CC       /tmp/build/perf/sigchain.o
  CC       /tmp/build/perf/parse-utils.o
  CC       /tmp/build/perf/kbuffer-parse.o
  CC       /tmp/build/perf/tep_strerror.o
  CC       /tmp/build/perf/subcmd-config.o
  CC       /tmp/build/perf/event-parse-api.o
  MKDIR    /tmp/build/perf/pmu-events/
  MKDIR    /tmp/build/perf/pmu-events/
  LD       /tmp/build/perf/libsubcmd-in.o
  HOSTCC   /tmp/build/perf/pmu-events/json.o
  HOSTCC   /tmp/build/perf/pmu-events/jsmn.o
  LD       /tmp/build/perf/libtraceevent-in.o
  LINK     /tmp/build/perf/libtraceevent.a
  AR       /tmp/build/perf/libsubcmd.a
  MKDIR    /tmp/build/perf/pmu-events/
  HOSTCC   /tmp/build/perf/pmu-events/jevents.o
  CC       /tmp/build/perf/plugin_kvm.o
  CC       /tmp/build/perf/plugin_kmem.o
  CC       /tmp/build/perf/plugin_jbd2.o
  CC       /tmp/build/perf/plugin_hrtimer.o
  CC       /tmp/build/perf/plugin_mac80211.o
  HOSTLD   /tmp/build/perf/pmu-events/jevents-in.o
  CC       /tmp/build/perf/plugin_sched_switch.o
  LD       /tmp/build/perf/plugin_kmem-in.o
  LD       /tmp/build/perf/plugin_jbd2-in.o
  LD       /tmp/build/perf/plugin_mac80211-in.o
  LD       /tmp/build/perf/plugin_hrtimer-in.o
  LINK     /tmp/build/perf/pmu-events/jevents
  LD       /tmp/build/perf/plugin_kvm-in.o
  CC       /tmp/build/perf/plugin_xen.o
  CC       /tmp/build/perf/plugin_function.o
  CC       /tmp/build/perf/plugin_scsi.o
  PERF_VERSION = 5.1.0-rc6
  CC       /tmp/build/perf/plugin_cfg80211.o
  GEN      perf-archive
  GEN      perf-with-kcore
  LD       /tmp/build/perf/plugin_sched_switch-in.o
  GEN      /tmp/build/perf/pmu-events/pmu-events.c
  LINK     /tmp/build/perf/plugin_jbd2.so
  LINK     /tmp/build/perf/plugin_hrtimer.so
  CC       /tmp/build/perf/pmu-events/pmu-events.o
  LD       /tmp/build/perf/plugin_xen-in.o
  LD       /tmp/build/perf/plugin_cfg80211-in.o
  LD       /tmp/build/perf/plugin_function-in.o
  LD       /tmp/build/perf/plugin_scsi-in.o
  LINK     /tmp/build/perf/plugin_kmem.so
  LINK     /tmp/build/perf/plugin_kvm.so
  LINK     /tmp/build/perf/plugin_mac80211.so
  LINK     /tmp/build/perf/plugin_sched_switch.so
  LINK     /tmp/build/perf/plugin_function.so
  LINK     /tmp/build/perf/plugin_xen.so
  LD       /tmp/build/perf/pmu-events/pmu-events-in.o
  LINK     /tmp/build/perf/plugin_scsi.so
  LINK     /tmp/build/perf/plugin_cfg80211.so
  GEN      /tmp/build/perf/libtraceevent-dynamic-list
  LD       /tmp/build/perf/libperf-in.o
  CC       /tmp/build/perf/builtin-config.o
  CC       /tmp/build/perf/builtin-bench.o
  CC       /tmp/build/perf/builtin-annotate.o
  CC       /tmp/build/perf/builtin-diff.o
  CC       /tmp/build/perf/builtin-ftrace.o
  CC       /tmp/build/perf/builtin-evlist.o
  CC       /tmp/build/perf/builtin-help.o
  CC       /tmp/build/perf/builtin-sched.o
  CC       /tmp/build/perf/builtin-buildid-list.o
  CC       /tmp/build/perf/builtin-buildid-cache.o
  CC       /tmp/build/perf/builtin-kallsyms.o
  CC       /tmp/build/perf/builtin-list.o
  CC       /tmp/build/perf/builtin-record.o
  CC       /tmp/build/perf/builtin-report.o
  CC       /tmp/build/perf/builtin-stat.o
  CC       /tmp/build/perf/builtin-timechart.o
  CC       /tmp/build/perf/builtin-top.o
  CC       /tmp/build/perf/builtin-script.o
  CC       /tmp/build/perf/builtin-kmem.o
  CC       /tmp/build/perf/builtin-lock.o
  CC       /tmp/build/perf/builtin-kvm.o
  CC       /tmp/build/perf/builtin-inject.o
  CC       /tmp/build/perf/builtin-mem.o
  CC       /tmp/build/perf/builtin-data.o
  CC       /tmp/build/perf/builtin-version.o
  CC       /tmp/build/perf/builtin-probe.o
  CC       /tmp/build/perf/builtin-c2c.o
  MKDIR    /tmp/build/perf/bench/
  MKDIR    /tmp/build/perf/tests/
  CC       /tmp/build/perf/bench/sched-messaging.o
  MKDIR    /tmp/build/perf/bench/
  CC       /tmp/build/perf/tests/builtin-test.o
  CC       /tmp/build/perf/bench/sched-pipe.o
  CC       /tmp/build/perf/bench/mem-functions.o
  CC       /tmp/build/perf/bench/futex-hash.o
  CC       /tmp/build/perf/bench/futex-wake.o
In file included from bench/futex-hash.c:26:
bench/futex.h: In function ?futex_wait?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:46:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h:37:10: note: each undeclared identifier is reported only once for each function it appears in
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:46:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ?futex_wake?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:56:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_WAKE, nr_wake, NULL, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ?futex_lock_pi?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:65:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_LOCK_PI, 0, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ?futex_unlock_pi?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:74:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_UNLOCK_PI, 0, NULL, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ?futex_cmp_requeue?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:86:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_CMP_REQUEUE, nr_wake, nr_requeue, uaddr2,
         ^~~~~
bench/futex.h: In function ?futex_wait?:
bench/futex.h:47:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
mv: cannot stat '/tmp/build/perf/bench/.futex-hash.o.tmp': No such file or directory
make[4]: *** [/git/perf/tools/build/Makefile.build:96: /tmp/build/perf/bench/futex-hash.o] Error 1
make[4]: *** Waiting for unfinished jobs....
  MKDIR    /tmp/build/perf/tests/
  MKDIR    /tmp/build/perf/arch/
  MKDIR    /tmp/build/perf/util/
  CC       /tmp/build/perf/tests/parse-events.o
  CC       /tmp/build/perf/util/annotate.o
  CC       /tmp/build/perf/arch/common.o
In file included from bench/futex-wake.c:24:
bench/futex.h: In function ?futex_wait?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:46:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h:37:10: note: each undeclared identifier is reported only once for each function it appears in
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:46:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ?futex_wake?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:56:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_WAKE, nr_wake, NULL, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ?futex_lock_pi?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:65:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_LOCK_PI, 0, timeout, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ?futex_unlock_pi?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:74:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_UNLOCK_PI, 0, NULL, NULL, 0, opflags);
         ^~~~~
bench/futex.h: In function ?futex_cmp_requeue?:
bench/futex.h:37:10: error: ?SYS_futex? undeclared (first use in this function); did you mean ?SYS_tee??
  syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
          ^~~~~~~~~
bench/futex.h:86:9: note: in expansion of macro ?futex?
  return futex(uaddr, FUTEX_CMP_REQUEUE, nr_wake, nr_requeue, uaddr2,
         ^~~~~
bench/futex.h: In function ?futex_wait?:
bench/futex.h:47:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
bench/futex.h: In function ?futex_wake?:
bench/futex.h:57:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
  MKDIR    /tmp/build/perf/util/
mv: cannot stat '/tmp/build/perf/bench/.futex-wake.o.tmp': No such file or directory
make[4]: *** [/git/perf/tools/build/Makefile.build:96: /tmp/build/perf/bench/futex-wake.o] Error 1
make[3]: *** [/git/perf/tools/build/Makefile.build:139: bench] Error 2
make[3]: *** Waiting for unfinished jobs....
  CC       /tmp/build/perf/util/block-range.o
  CC       /tmp/build/perf/util/build-id.o
  MKDIR    /tmp/build/perf/ui/
  CC       /tmp/build/perf/ui/setup.o
  CC       /tmp/build/perf/util/config.o
  MKDIR    /tmp/build/perf/ui/
  MKDIR    /tmp/build/perf/arch/arc/
  CC       /tmp/build/perf/ui/progress.o
  CC       /tmp/build/perf/ui/helpline.o
  LD       /tmp/build/perf/arch/arc/perf-in.o
  LD       /tmp/build/perf/arch/perf-in.o
  CC       /tmp/build/perf/ui/util.o
  CC       /tmp/build/perf/ui/hist.o
  CC       /tmp/build/perf/tests/dso-data.o
  CC       /tmp/build/perf/util/ctype.o
  MKDIR    /tmp/build/perf/ui/stdio/
  CC       /tmp/build/perf/ui/stdio/hist.o
  CC       /tmp/build/perf/tests/attr.o
  CC       /tmp/build/perf/tests/vmlinux-kallsyms.o
  CC       /tmp/build/perf/util/db-export.o
  CC       /tmp/build/perf/tests/openat-syscall.o
  CC       /tmp/build/perf/tests/openat-syscall-all-cpus.o
  CC       /tmp/build/perf/tests/openat-syscall-tp-fields.o
  CC       /tmp/build/perf/util/env.o
  CC       /tmp/build/perf/util/event.o
  CC       /tmp/build/perf/util/evlist.o
  CC       /tmp/build/perf/tests/mmap-basic.o
  CC       /tmp/build/perf/util/evsel.o
  CC       /tmp/build/perf/util/evsel_fprintf.o
  CC       /tmp/build/perf/util/find_bit.o
  CC       /tmp/build/perf/util/get_current_dir_name.o
  CC       /tmp/build/perf/util/kallsyms.o
  CC       /tmp/build/perf/util/levenshtein.o
  CC       /tmp/build/perf/tests/perf-record.o
  CC       /tmp/build/perf/util/llvm-utils.o
  CC       /tmp/build/perf/tests/evsel-roundtrip-name.o
  CC       /tmp/build/perf/tests/evsel-tp-sched.o
  LD       /tmp/build/perf/ui/perf-in.o
  CC       /tmp/build/perf/tests/fdarray.o
  CC       /tmp/build/perf/util/mmap.o

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-26 19:28       ` Arnaldo Carvalho de Melo
  (?)
@ 2019-04-26 19:35         ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-26 19:35 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: linux-perf-users, Arnaldo Carvalho de Melo, lkml, arcml,
	Arnd Bergmann, Jiri Olsa, Namhyung Kim

Em Fri, Apr 26, 2019 at 04:28:34PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Apr 25, 2019 at 06:48:00PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> > > > When building perf for ARC (v5.1-rc2) I get the following
> > >  
> > > > | In file included from bench/futex-hash.c:26:
> > > > | bench/futex.h: In function 'futex_wait':
> > > > | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
> > >  
> > > > git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> > > > Sync copy of asm-generic/unistd.h with the kernel sources")
> > > 
> > > Humm, I have to check why this:
> > > 
> > > [perfbuilder@quaco ~]$ podman images | grep ARC
> > > docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> > > [perfbuilder@quaco ~]$
> > > 
> > > isn't catching this... :-\
> > > 
> > > FROM docker.io/fedora:24
> > > MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> > > ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> > > ENV CROSS=arc-linux-
> > > ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> > > RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> > > RUN wget https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-rc2/${SOURCEFILE}
> > > <SNIP>
> > > COPY rx_and_build.sh /
> > > ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> > > ENV ARCH=arc
> > > ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> > > ENV EXTRA_CFLAGS=-matomic
> > 
> > So, now I have a libnuma crossbuilt in this container that allows me to
> > build a ARC perf binary linked with zlib and numactl-devel, but only
> > after I applied the fix below.
> > 
> > Can you please provide the feature detection header in the build? I.e.
> > what I have with my ARC cross build container right now, after applying
> > the patch below is:
> 
> So, switched from the uCLibc build system to the glibc based one, so
> that I could get elfutils building (it needs argp that isn't available
> with uCLibc) I have it reproduced, see below, now I'm testing with the
> fix, which is to grab the unistd.h files you noticed missing for the
> arches that are present in tools/arch/, will post results soon

Yep, now it builds:

/tmp/build/perf/perf: ELF 32-bit LSB executable, *unknown arch 0xc3* version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-arc.so.2, for GNU/Linux 3.9.0, with debug_info, not stripped

With this patch:

commit dd423246b321967eace3f3e0fe73d638050b447c
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Apr 22 15:21:35 2019 -0300

    WIP
    
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

diff --git a/tools/arch/arc/include/uapi/asm/unistd.h b/tools/arch/arc/include/uapi/asm/unistd.h
new file mode 100644
index 000000000000..5eafa1115162
--- /dev/null
+++ b/tools/arch/arc/include/uapi/asm/unistd.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/******** no-legacy-syscalls-ABI *******/
+
+/*
+ * Non-typical guard macro to enable inclusion twice in ARCH sys.c
+ * That is how the Generic syscall wrapper generator works
+ */
+#if !defined(_UAPI_ASM_ARC_UNISTD_H) || defined(__SYSCALL)
+#define _UAPI_ASM_ARC_UNISTD_H
+
+#define __ARCH_WANT_RENAMEAT
+#define __ARCH_WANT_STAT64
+#define __ARCH_WANT_SET_GET_RLIMIT
+#define __ARCH_WANT_SYS_EXECVE
+#define __ARCH_WANT_SYS_CLONE
+#define __ARCH_WANT_SYS_VFORK
+#define __ARCH_WANT_SYS_FORK
+#define __ARCH_WANT_TIME32_SYSCALLS
+
+#define sys_mmap2 sys_mmap_pgoff
+
+#include <asm-generic/unistd.h>
+
+#define NR_syscalls	__NR_syscalls
+
+/* Generic syscall (fs/filesystems.c - lost in asm-generic/unistd.h */
+#define __NR_sysfs		(__NR_arch_specific_syscall + 3)
+
+/* ARC specific syscall */
+#define __NR_cacheflush		(__NR_arch_specific_syscall + 0)
+#define __NR_arc_settls		(__NR_arch_specific_syscall + 1)
+#define __NR_arc_gettls		(__NR_arch_specific_syscall + 2)
+#define __NR_arc_usr_cmpxchg	(__NR_arch_specific_syscall + 4)
+
+__SYSCALL(__NR_cacheflush, sys_cacheflush)
+__SYSCALL(__NR_arc_settls, sys_arc_settls)
+__SYSCALL(__NR_arc_gettls, sys_arc_gettls)
+__SYSCALL(__NR_arc_usr_cmpxchg, sys_arc_usr_cmpxchg)
+__SYSCALL(__NR_sysfs, sys_sysfs)
+
+#undef __SYSCALL
+
+#endif
diff --git a/tools/arch/hexagon/include/uapi/asm/unistd.h b/tools/arch/hexagon/include/uapi/asm/unistd.h
new file mode 100644
index 000000000000..432c4db1b623
--- /dev/null
+++ b/tools/arch/hexagon/include/uapi/asm/unistd.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Syscall support for Hexagon
+ *
+ * Copyright (c) 2010-2011, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+/*
+ *  The kernel pulls this unistd.h in three different ways:
+ *  1.  the "normal" way which gets all the __NR defines
+ *  2.  with __SYSCALL defined to produce function declarations
+ *  3.  with __SYSCALL defined to produce syscall table initialization
+ *  See also:  syscalltab.c
+ */
+
+#define sys_mmap2 sys_mmap_pgoff
+#define __ARCH_WANT_RENAMEAT
+#define __ARCH_WANT_STAT64
+#define __ARCH_WANT_SET_GET_RLIMIT
+#define __ARCH_WANT_SYS_EXECVE
+#define __ARCH_WANT_SYS_CLONE
+#define __ARCH_WANT_SYS_VFORK
+#define __ARCH_WANT_SYS_FORK
+#define __ARCH_WANT_TIME32_SYSCALLS
+
+#include <asm-generic/unistd.h>
diff --git a/tools/arch/riscv/include/uapi/asm/unistd.h b/tools/arch/riscv/include/uapi/asm/unistd.h
new file mode 100644
index 000000000000..0e2eeeb1fd27
--- /dev/null
+++ b/tools/arch/riscv/include/uapi/asm/unistd.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2018 David Abdurachmanov <david.abdurachmanov@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifdef __LP64__
+#define __ARCH_WANT_NEW_STAT
+#define __ARCH_WANT_SET_GET_RLIMIT
+#endif /* __LP64__ */
+
+#include <asm-generic/unistd.h>
+
+/*
+ * Allows the instruction cache to be flushed from userspace.  Despite RISC-V
+ * having a direct 'fence.i' instruction available to userspace (which we
+ * can't trap!), that's not actually viable when running on Linux because the
+ * kernel might schedule a process on another hart.  There is no way for
+ * userspace to handle this without invoking the kernel (as it doesn't know the
+ * thread->hart mappings), so we've defined a RISC-V specific system call to
+ * flush the instruction cache.
+ *
+ * __NR_riscv_flush_icache is defined to flush the instruction cache over an
+ * address range, with the flush applying to either all threads or just the
+ * caller.  We don't currently do anything with the address range, that's just
+ * in there for forwards compatibility.
+ */
+#ifndef __NR_riscv_flush_icache
+#define __NR_riscv_flush_icache (__NR_arch_specific_syscall + 15)
+#endif
+__SYSCALL(__NR_riscv_flush_icache, sys_riscv_flush_icache)

^ permalink raw reply related	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
@ 2019-04-26 19:35         ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-26 19:35 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnaldo Carvalho de Melo, Arnd Bergmann, lkml, linux-perf-users,
	Jiri Olsa, Namhyung Kim, arcml

Em Fri, Apr 26, 2019 at 04:28:34PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Apr 25, 2019 at 06:48:00PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> > > > When building perf for ARC (v5.1-rc2) I get the following
> > >  
> > > > | In file included from bench/futex-hash.c:26:
> > > > | bench/futex.h: In function 'futex_wait':
> > > > | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
> > >  
> > > > git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> > > > Sync copy of asm-generic/unistd.h with the kernel sources")
> > > 
> > > Humm, I have to check why this:
> > > 
> > > [perfbuilder@quaco ~]$ podman images | grep ARC
> > > docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> > > [perfbuilder@quaco ~]$
> > > 
> > > isn't catching this... :-\
> > > 
> > > FROM docker.io/fedora:24
> > > MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> > > ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> > > ENV CROSS=arc-linux-
> > > ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> > > RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> > > RUN wget https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-rc2/${SOURCEFILE}
> > > <SNIP>
> > > COPY rx_and_build.sh /
> > > ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> > > ENV ARCH=arc
> > > ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> > > ENV EXTRA_CFLAGS=-matomic
> > 
> > So, now I have a libnuma crossbuilt in this container that allows me to
> > build a ARC perf binary linked with zlib and numactl-devel, but only
> > after I applied the fix below.
> > 
> > Can you please provide the feature detection header in the build? I.e.
> > what I have with my ARC cross build container right now, after applying
> > the patch below is:
> 
> So, switched from the uCLibc build system to the glibc based one, so
> that I could get elfutils building (it needs argp that isn't available
> with uCLibc) I have it reproduced, see below, now I'm testing with the
> fix, which is to grab the unistd.h files you noticed missing for the
> arches that are present in tools/arch/, will post results soon

Yep, now it builds:

/tmp/build/perf/perf: ELF 32-bit LSB executable, *unknown arch 0xc3* version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-arc.so.2, for GNU/Linux 3.9.0, with debug_info, not stripped

With this patch:

commit dd423246b321967eace3f3e0fe73d638050b447c
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Apr 22 15:21:35 2019 -0300

    WIP
    
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

diff --git a/tools/arch/arc/include/uapi/asm/unistd.h b/tools/arch/arc/include/uapi/asm/unistd.h
new file mode 100644
index 000000000000..5eafa1115162
--- /dev/null
+++ b/tools/arch/arc/include/uapi/asm/unistd.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/******** no-legacy-syscalls-ABI *******/
+
+/*
+ * Non-typical guard macro to enable inclusion twice in ARCH sys.c
+ * That is how the Generic syscall wrapper generator works
+ */
+#if !defined(_UAPI_ASM_ARC_UNISTD_H) || defined(__SYSCALL)
+#define _UAPI_ASM_ARC_UNISTD_H
+
+#define __ARCH_WANT_RENAMEAT
+#define __ARCH_WANT_STAT64
+#define __ARCH_WANT_SET_GET_RLIMIT
+#define __ARCH_WANT_SYS_EXECVE
+#define __ARCH_WANT_SYS_CLONE
+#define __ARCH_WANT_SYS_VFORK
+#define __ARCH_WANT_SYS_FORK
+#define __ARCH_WANT_TIME32_SYSCALLS
+
+#define sys_mmap2 sys_mmap_pgoff
+
+#include <asm-generic/unistd.h>
+
+#define NR_syscalls	__NR_syscalls
+
+/* Generic syscall (fs/filesystems.c - lost in asm-generic/unistd.h */
+#define __NR_sysfs		(__NR_arch_specific_syscall + 3)
+
+/* ARC specific syscall */
+#define __NR_cacheflush		(__NR_arch_specific_syscall + 0)
+#define __NR_arc_settls		(__NR_arch_specific_syscall + 1)
+#define __NR_arc_gettls		(__NR_arch_specific_syscall + 2)
+#define __NR_arc_usr_cmpxchg	(__NR_arch_specific_syscall + 4)
+
+__SYSCALL(__NR_cacheflush, sys_cacheflush)
+__SYSCALL(__NR_arc_settls, sys_arc_settls)
+__SYSCALL(__NR_arc_gettls, sys_arc_gettls)
+__SYSCALL(__NR_arc_usr_cmpxchg, sys_arc_usr_cmpxchg)
+__SYSCALL(__NR_sysfs, sys_sysfs)
+
+#undef __SYSCALL
+
+#endif
diff --git a/tools/arch/hexagon/include/uapi/asm/unistd.h b/tools/arch/hexagon/include/uapi/asm/unistd.h
new file mode 100644
index 000000000000..432c4db1b623
--- /dev/null
+++ b/tools/arch/hexagon/include/uapi/asm/unistd.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Syscall support for Hexagon
+ *
+ * Copyright (c) 2010-2011, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+/*
+ *  The kernel pulls this unistd.h in three different ways:
+ *  1.  the "normal" way which gets all the __NR defines
+ *  2.  with __SYSCALL defined to produce function declarations
+ *  3.  with __SYSCALL defined to produce syscall table initialization
+ *  See also:  syscalltab.c
+ */
+
+#define sys_mmap2 sys_mmap_pgoff
+#define __ARCH_WANT_RENAMEAT
+#define __ARCH_WANT_STAT64
+#define __ARCH_WANT_SET_GET_RLIMIT
+#define __ARCH_WANT_SYS_EXECVE
+#define __ARCH_WANT_SYS_CLONE
+#define __ARCH_WANT_SYS_VFORK
+#define __ARCH_WANT_SYS_FORK
+#define __ARCH_WANT_TIME32_SYSCALLS
+
+#include <asm-generic/unistd.h>
diff --git a/tools/arch/riscv/include/uapi/asm/unistd.h b/tools/arch/riscv/include/uapi/asm/unistd.h
new file mode 100644
index 000000000000..0e2eeeb1fd27
--- /dev/null
+++ b/tools/arch/riscv/include/uapi/asm/unistd.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2018 David Abdurachmanov <david.abdurachmanov@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifdef __LP64__
+#define __ARCH_WANT_NEW_STAT
+#define __ARCH_WANT_SET_GET_RLIMIT
+#endif /* __LP64__ */
+
+#include <asm-generic/unistd.h>
+
+/*
+ * Allows the instruction cache to be flushed from userspace.  Despite RISC-V
+ * having a direct 'fence.i' instruction available to userspace (which we
+ * can't trap!), that's not actually viable when running on Linux because the
+ * kernel might schedule a process on another hart.  There is no way for
+ * userspace to handle this without invoking the kernel (as it doesn't know the
+ * thread->hart mappings), so we've defined a RISC-V specific system call to
+ * flush the instruction cache.
+ *
+ * __NR_riscv_flush_icache is defined to flush the instruction cache over an
+ * address range, with the flush applying to either all threads or just the
+ * caller.  We don't currently do anything with the address range, that's just
+ * in there for forwards compatibility.
+ */
+#ifndef __NR_riscv_flush_icache
+#define __NR_riscv_flush_icache (__NR_arch_specific_syscall + 15)
+#endif
+__SYSCALL(__NR_riscv_flush_icache, sys_riscv_flush_icache)

^ permalink raw reply related	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-26 19:35         ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-26 19:35 UTC (permalink / raw)
  To: linux-snps-arc

Em Fri, Apr 26, 2019 at 04:28:34PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Apr 25, 2019 at 06:48:00PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> > > > When building perf for ARC (v5.1-rc2) I get the following
> > >  
> > > > | In file included from bench/futex-hash.c:26:
> > > > | bench/futex.h: In function 'futex_wait':
> > > > | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
> > >  
> > > > git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> > > > Sync copy of asm-generic/unistd.h with the kernel sources")
> > > 
> > > Humm, I have to check why this:
> > > 
> > > [perfbuilder at quaco ~]$ podman images | grep ARC
> > > docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> > > [perfbuilder at quaco ~]$
> > > 
> > > isn't catching this... :-\
> > > 
> > > FROM docker.io/fedora:24
> > > MAINTAINER Arnaldo Carvalho de Melo <acme at kernel.org>
> > > ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> > > ENV CROSS=arc-linux-
> > > ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> > > RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> > > RUN wget https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-rc2/${SOURCEFILE}
> > > <SNIP>
> > > COPY rx_and_build.sh /
> > > ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> > > ENV ARCH=arc
> > > ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> > > ENV EXTRA_CFLAGS=-matomic
> > 
> > So, now I have a libnuma crossbuilt in this container that allows me to
> > build a ARC perf binary linked with zlib and numactl-devel, but only
> > after I applied the fix below.
> > 
> > Can you please provide the feature detection header in the build? I.e.
> > what I have with my ARC cross build container right now, after applying
> > the patch below is:
> 
> So, switched from the uCLibc build system to the glibc based one, so
> that I could get elfutils building (it needs argp that isn't available
> with uCLibc) I have it reproduced, see below, now I'm testing with the
> fix, which is to grab the unistd.h files you noticed missing for the
> arches that are present in tools/arch/, will post results soon

Yep, now it builds:

/tmp/build/perf/perf: ELF 32-bit LSB executable, *unknown arch 0xc3* version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-arc.so.2, for GNU/Linux 3.9.0, with debug_info, not stripped

With this patch:

commit dd423246b321967eace3f3e0fe73d638050b447c
Author: Arnaldo Carvalho de Melo <acme at redhat.com>
Date:   Mon Apr 22 15:21:35 2019 -0300

    WIP
    
    Signed-off-by: Arnaldo Carvalho de Melo <acme at redhat.com>

diff --git a/tools/arch/arc/include/uapi/asm/unistd.h b/tools/arch/arc/include/uapi/asm/unistd.h
new file mode 100644
index 000000000000..5eafa1115162
--- /dev/null
+++ b/tools/arch/arc/include/uapi/asm/unistd.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/******** no-legacy-syscalls-ABI *******/
+
+/*
+ * Non-typical guard macro to enable inclusion twice in ARCH sys.c
+ * That is how the Generic syscall wrapper generator works
+ */
+#if !defined(_UAPI_ASM_ARC_UNISTD_H) || defined(__SYSCALL)
+#define _UAPI_ASM_ARC_UNISTD_H
+
+#define __ARCH_WANT_RENAMEAT
+#define __ARCH_WANT_STAT64
+#define __ARCH_WANT_SET_GET_RLIMIT
+#define __ARCH_WANT_SYS_EXECVE
+#define __ARCH_WANT_SYS_CLONE
+#define __ARCH_WANT_SYS_VFORK
+#define __ARCH_WANT_SYS_FORK
+#define __ARCH_WANT_TIME32_SYSCALLS
+
+#define sys_mmap2 sys_mmap_pgoff
+
+#include <asm-generic/unistd.h>
+
+#define NR_syscalls	__NR_syscalls
+
+/* Generic syscall (fs/filesystems.c - lost in asm-generic/unistd.h */
+#define __NR_sysfs		(__NR_arch_specific_syscall + 3)
+
+/* ARC specific syscall */
+#define __NR_cacheflush		(__NR_arch_specific_syscall + 0)
+#define __NR_arc_settls		(__NR_arch_specific_syscall + 1)
+#define __NR_arc_gettls		(__NR_arch_specific_syscall + 2)
+#define __NR_arc_usr_cmpxchg	(__NR_arch_specific_syscall + 4)
+
+__SYSCALL(__NR_cacheflush, sys_cacheflush)
+__SYSCALL(__NR_arc_settls, sys_arc_settls)
+__SYSCALL(__NR_arc_gettls, sys_arc_gettls)
+__SYSCALL(__NR_arc_usr_cmpxchg, sys_arc_usr_cmpxchg)
+__SYSCALL(__NR_sysfs, sys_sysfs)
+
+#undef __SYSCALL
+
+#endif
diff --git a/tools/arch/hexagon/include/uapi/asm/unistd.h b/tools/arch/hexagon/include/uapi/asm/unistd.h
new file mode 100644
index 000000000000..432c4db1b623
--- /dev/null
+++ b/tools/arch/hexagon/include/uapi/asm/unistd.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Syscall support for Hexagon
+ *
+ * Copyright (c) 2010-2011, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+/*
+ *  The kernel pulls this unistd.h in three different ways:
+ *  1.  the "normal" way which gets all the __NR defines
+ *  2.  with __SYSCALL defined to produce function declarations
+ *  3.  with __SYSCALL defined to produce syscall table initialization
+ *  See also:  syscalltab.c
+ */
+
+#define sys_mmap2 sys_mmap_pgoff
+#define __ARCH_WANT_RENAMEAT
+#define __ARCH_WANT_STAT64
+#define __ARCH_WANT_SET_GET_RLIMIT
+#define __ARCH_WANT_SYS_EXECVE
+#define __ARCH_WANT_SYS_CLONE
+#define __ARCH_WANT_SYS_VFORK
+#define __ARCH_WANT_SYS_FORK
+#define __ARCH_WANT_TIME32_SYSCALLS
+
+#include <asm-generic/unistd.h>
diff --git a/tools/arch/riscv/include/uapi/asm/unistd.h b/tools/arch/riscv/include/uapi/asm/unistd.h
new file mode 100644
index 000000000000..0e2eeeb1fd27
--- /dev/null
+++ b/tools/arch/riscv/include/uapi/asm/unistd.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2018 David Abdurachmanov <david.abdurachmanov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifdef __LP64__
+#define __ARCH_WANT_NEW_STAT
+#define __ARCH_WANT_SET_GET_RLIMIT
+#endif /* __LP64__ */
+
+#include <asm-generic/unistd.h>
+
+/*
+ * Allows the instruction cache to be flushed from userspace.  Despite RISC-V
+ * having a direct 'fence.i' instruction available to userspace (which we
+ * can't trap!), that's not actually viable when running on Linux because the
+ * kernel might schedule a process on another hart.  There is no way for
+ * userspace to handle this without invoking the kernel (as it doesn't know the
+ * thread->hart mappings), so we've defined a RISC-V specific system call to
+ * flush the instruction cache.
+ *
+ * __NR_riscv_flush_icache is defined to flush the instruction cache over an
+ * address range, with the flush applying to either all threads or just the
+ * caller.  We don't currently do anything with the address range, that's just
+ * in there for forwards compatibility.
+ */
+#ifndef __NR_riscv_flush_icache
+#define __NR_riscv_flush_icache (__NR_arch_specific_syscall + 15)
+#endif
+__SYSCALL(__NR_riscv_flush_icache, sys_riscv_flush_icache)

^ permalink raw reply related	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-25 21:48     ` Arnaldo Carvalho de Melo
@ 2019-04-29 17:14       ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-29 17:14 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: linux-perf-users, Arnaldo Carvalho de Melo, lkml, arcml,
	Arnd Bergmann, Jiri Olsa, Namhyung Kim

On 4/25/19 2:48 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
>>> When building perf for ARC (v5.1-rc2) I get the following
>>  
>>> | In file included from bench/futex-hash.c:26:
>>> | bench/futex.h: In function 'futex_wait':
>>> | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
>>  
>>> git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
>>> Sync copy of asm-generic/unistd.h with the kernel sources")
>> Humm, I have to check why this:
>>
>> [perfbuilder@quaco ~]$ podman images | grep ARC
>> docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
>> [perfbuilder@quaco ~]$
>>
>> isn't catching this... :-\
>>
>> FROM docker.io/fedora:24
>> MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
>> ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
>> ENV CROSS=arc-linux-
>> ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
>> RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
>> RUN wget https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_foss-2Dfor-2Dsynopsys-2Ddwc-2Darc-2Dprocessors_toolchain_releases_download_arc-2D2017.09-2Drc2_-24-257BSOURCEFILE-257D&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=HjtufCLozrW47pS5C2YH3safLHQE7eEtmHFZsSWrz1M&s=29g4oKvGuYcLgheCUvZh3wojhhljivpLd8aj7Ur4sKQ&e=
>> <SNIP>
>> COPY rx_and_build.sh /
>> ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
>> ENV ARCH=arc
>> ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
>> ENV EXTRA_CFLAGS=-matomic
> So, now I have a libnuma crossbuilt in this container that allows me to
> build a ARC perf binary linked with zlib and numactl-devel, but only
> after I applied the fix below.
>
> Can you please provide the feature detection header in the build? I.e.
> what I have with my ARC cross build container right now, after applying
> the patch below is:
>
> [perfbuilder@60d5802468f6 perf]$ make $EXTRA_MAKE_ARGS ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE EXTRA_CFLAGS="$EXTRA_CFLAGS" -C /git/perf/tools/perf O=/tmp/build/perf
> make: Entering directory '/git/perf/tools/perf'
>   BUILD:   Doing 'make -j8' parallel build
> sh: line 0: command: -c: invalid option
> command: usage: command [-pVv] command [arg ...]
>
> Auto-detecting system features:
> ...                         dwarf: [ OFF ]
> ...            dwarf_getlocations: [ OFF ]
> ...                         glibc: [ on  ]

Not related to current issue, this run uses a uClibc toolchain and yet it is
detecting glibc - doesn't seem right to me.

> ...                          gtk2: [ OFF ]
> ...                      libaudit: [ OFF ]
> ...                        libbfd: [ OFF ]
> ...                        libelf: [ OFF ]
> ...                       libnuma: [ on  ]

Wondering why that is - for me numa is off - even when using a glibc toolchain.

> ...        numa_num_possible_cpus: [ on  ]
> ...                       libperl: [ OFF ]
> ...                     libpython: [ OFF ]
> ...                      libslang: [ OFF ]
> ...                     libcrypto: [ OFF ]
> ...                     libunwind: [ OFF ]
> ...            libdw-dwarf-unwind: [ OFF ]
> ...                          zlib: [ OFF ]
> ...                          lzma: [ OFF ]
> ...                     get_cpuid: [ OFF ]
> ...                           bpf: [ on  ]
> ...                        libaio: [ OFF ]
> ...        disassembler-four-args: [ OFF ]
>
>

For my glibc toolchain, here's the feature detection output

Auto-detecting system features:
...                         dwarf: [ on  ]
...            dwarf_getlocations: [ OFF ]
...                         glibc: [ on  ]
...                          gtk2: [ OFF ]
...                      libaudit: [ OFF ]
...                        libbfd: [ OFF ]
...                        libelf: [ on  ]
...                       libnuma: [ OFF ]
...        numa_num_possible_cpus: [ OFF ]
...                       libperl: [ OFF ]
...                     libpython: [ OFF ]
...                      libslang: [ OFF ]
...                     libcrypto: [ OFF ]
...                     libunwind: [ OFF ]
...            libdw-dwarf-unwind: [ OFF ]
...                          zlib: [ OFF ]
...                          lzma: [ OFF ]
...                     get_cpuid: [ OFF ]
...                           bpf: [ on  ]
...                        libaio: [ on  ]
...        disassembler-four-args: [ OFF ]



^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-29 17:14       ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-29 17:14 UTC (permalink / raw)
  To: linux-snps-arc

On 4/25/19 2:48 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
>>> When building perf for ARC (v5.1-rc2) I get the following
>>  
>>> | In file included from bench/futex-hash.c:26:
>>> | bench/futex.h: In function 'futex_wait':
>>> | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
>>  
>>> git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
>>> Sync copy of asm-generic/unistd.h with the kernel sources")
>> Humm, I have to check why this:
>>
>> [perfbuilder at quaco ~]$ podman images | grep ARC
>> docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
>> [perfbuilder at quaco ~]$
>>
>> isn't catching this... :-\
>>
>> FROM docker.io/fedora:24
>> MAINTAINER Arnaldo Carvalho de Melo <acme at kernel.org>
>> ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
>> ENV CROSS=arc-linux-
>> ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
>> RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
>> RUN wget https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_foss-2Dfor-2Dsynopsys-2Ddwc-2Darc-2Dprocessors_toolchain_releases_download_arc-2D2017.09-2Drc2_-24-257BSOURCEFILE-257D&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=HjtufCLozrW47pS5C2YH3safLHQE7eEtmHFZsSWrz1M&s=29g4oKvGuYcLgheCUvZh3wojhhljivpLd8aj7Ur4sKQ&e=
>> <SNIP>
>> COPY rx_and_build.sh /
>> ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
>> ENV ARCH=arc
>> ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
>> ENV EXTRA_CFLAGS=-matomic
> So, now I have a libnuma crossbuilt in this container that allows me to
> build a ARC perf binary linked with zlib and numactl-devel, but only
> after I applied the fix below.
>
> Can you please provide the feature detection header in the build? I.e.
> what I have with my ARC cross build container right now, after applying
> the patch below is:
>
> [perfbuilder at 60d5802468f6 perf]$ make $EXTRA_MAKE_ARGS ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE EXTRA_CFLAGS="$EXTRA_CFLAGS" -C /git/perf/tools/perf O=/tmp/build/perf
> make: Entering directory '/git/perf/tools/perf'
>   BUILD:   Doing 'make -j8' parallel build
> sh: line 0: command: -c: invalid option
> command: usage: command [-pVv] command [arg ...]
>
> Auto-detecting system features:
> ...                         dwarf: [ OFF ]
> ...            dwarf_getlocations: [ OFF ]
> ...                         glibc: [ on  ]

Not related to current issue, this run uses a uClibc toolchain and yet it is
detecting glibc - doesn't seem right to me.

> ...                          gtk2: [ OFF ]
> ...                      libaudit: [ OFF ]
> ...                        libbfd: [ OFF ]
> ...                        libelf: [ OFF ]
> ...                       libnuma: [ on  ]

Wondering why that is - for me numa is off - even when using a glibc toolchain.

> ...        numa_num_possible_cpus: [ on  ]
> ...                       libperl: [ OFF ]
> ...                     libpython: [ OFF ]
> ...                      libslang: [ OFF ]
> ...                     libcrypto: [ OFF ]
> ...                     libunwind: [ OFF ]
> ...            libdw-dwarf-unwind: [ OFF ]
> ...                          zlib: [ OFF ]
> ...                          lzma: [ OFF ]
> ...                     get_cpuid: [ OFF ]
> ...                           bpf: [ on  ]
> ...                        libaio: [ OFF ]
> ...        disassembler-four-args: [ OFF ]
>
>

For my glibc toolchain, here's the feature detection output

Auto-detecting system features:
...                         dwarf: [ on  ]
...            dwarf_getlocations: [ OFF ]
...                         glibc: [ on  ]
...                          gtk2: [ OFF ]
...                      libaudit: [ OFF ]
...                        libbfd: [ OFF ]
...                        libelf: [ on  ]
...                       libnuma: [ OFF ]
...        numa_num_possible_cpus: [ OFF ]
...                       libperl: [ OFF ]
...                     libpython: [ OFF ]
...                      libslang: [ OFF ]
...                     libcrypto: [ OFF ]
...                     libunwind: [ OFF ]
...            libdw-dwarf-unwind: [ OFF ]
...                          zlib: [ OFF ]
...                          lzma: [ OFF ]
...                     get_cpuid: [ OFF ]
...                           bpf: [ on  ]
...                        libaio: [ on  ]
...        disassembler-four-args: [ OFF ]

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-22 15:20   ` Arnaldo Carvalho de Melo
@ 2019-04-29 17:17     ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-29 17:17 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Arnaldo Carvalho de Melo, Arnd Bergmann, lkml, linux-perf-users,
	Jiri Olsa, Namhyung Kim, arcml

On 4/22/19 8:31 AM, Arnaldo Carvalho de Melo wrote:
>> A quick fix for ARC will be to create our own version but I presume all existing
>> arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
>> send out a patch for ARC.
>>
>> P.S. Why do we need the unistd.h duplication in tools directory, given it could
>> have used the in-tree unistd headers directly ?
> I have to write down the explanation and have it in a file, but we can't
> use anything in the kernel from outside tools/ to avoid adding a burden
> to kernel developers that would then have to make sure that the changes
> that they make outside tools/ don't break things living there.

That is a sound guiding principle in general but I don't agree here. unistd is
backbone of kernel user interface it has to work and can't possibly be broken even
when kernel devs add a new syscall is added or condition-alize existing one. So
adding a copy - and deferring the propagation of in-kernel unistd to usersapce
won't necessarily help with anything and it just adds the burden of keeping them
in sync. Granted we won't necessarily need all the bleeding edge (new syscall
updates) into that header, its still more work.

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-29 17:17     ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-29 17:17 UTC (permalink / raw)
  To: linux-snps-arc

On 4/22/19 8:31 AM, Arnaldo Carvalho de Melo wrote:
>> A quick fix for ARC will be to create our own version but I presume all existing
>> arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
>> send out a patch for ARC.
>>
>> P.S. Why do we need the unistd.h duplication in tools directory, given it could
>> have used the in-tree unistd headers directly ?
> I have to write down the explanation and have it in a file, but we can't
> use anything in the kernel from outside tools/ to avoid adding a burden
> to kernel developers that would then have to make sure that the changes
> that they make outside tools/ don't break things living there.

That is a sound guiding principle in general but I don't agree here. unistd is
backbone of kernel user interface it has to work and can't possibly be broken even
when kernel devs add a new syscall is added or condition-alize existing one. So
adding a copy - and deferring the propagation of in-kernel unistd to usersapce
won't necessarily help with anything and it just adds the burden of keeping them
in sync. Granted we won't necessarily need all the bleeding edge (new syscall
updates) into that header, its still more work.

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-26 19:35         ` Arnaldo Carvalho de Melo
@ 2019-04-29 17:23           ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-29 17:23 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: linux-perf-users, Arnaldo Carvalho de Melo, lkml, arcml,
	Arnd Bergmann, Jiri Olsa, Namhyung Kim

On 4/26/19 12:35 PM, Arnaldo Carvalho de Melo wrote:
> Em Fri, Apr 26, 2019 at 04:28:34PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Apr 25, 2019 at 06:48:00PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
>>>>> When building perf for ARC (v5.1-rc2) I get the following
>>>>  
>>>>> | In file included from bench/futex-hash.c:26:
>>>>> | bench/futex.h: In function 'futex_wait':
>>>>> | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
>>>>  
>>>>> git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
>>>>> Sync copy of asm-generic/unistd.h with the kernel sources")
>>>> Humm, I have to check why this:
>>>>
>>>> [perfbuilder@quaco ~]$ podman images | grep ARC
>>>> docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
>>>> [perfbuilder@quaco ~]$
>>>>
>>>> isn't catching this... :-\
>>>>
>>>> FROM docker.io/fedora:24
>>>> MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
>>>> ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
>>>> ENV CROSS=arc-linux-
>>>> ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
>>>> RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
>>>> RUN wget https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_foss-2Dfor-2Dsynopsys-2Ddwc-2Darc-2Dprocessors_toolchain_releases_download_arc-2D2017.09-2Drc2_-24-257BSOURCEFILE-257D&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=obdUU5ZihUrFi8F2O4JfVYScd7CLKNItF83dHmezlkU&s=oOPRKzvGneimee7GFXWyqqoVfgvHu-jwSMKPbSqwP5M&e=
>>>> <SNIP>
>>>> COPY rx_and_build.sh /
>>>> ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
>>>> ENV ARCH=arc
>>>> ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
>>>> ENV EXTRA_CFLAGS=-matomic
>>> So, now I have a libnuma crossbuilt in this container that allows me to
>>> build a ARC perf binary linked with zlib and numactl-devel, but only
>>> after I applied the fix below.
>>>
>>> Can you please provide the feature detection header in the build? I.e.
>>> what I have with my ARC cross build container right now, after applying
>>> the patch below is:
>> So, switched from the uCLibc build system to the glibc based one, so
>> that I could get elfutils building (it needs argp that isn't available
>> with uCLibc) I have it reproduced, see below, now I'm testing with the
>> fix, which is to grab the unistd.h files you noticed missing for the
>> arches that are present in tools/arch/, will post results soon
> Yep, now it builds:
>
> /tmp/build/perf/perf: ELF 32-bit LSB executable, *unknown arch 0xc3* version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-arc.so.2, for GNU/Linux 3.9.0, with debug_info, not stripped
>
> With this patch:
>
> commit dd423246b321967eace3f3e0fe73d638050b447c
> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date:   Mon Apr 22 15:21:35 2019 -0300
>
>     WIP
>     
>     Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> diff --git a/tools/arch/arc/include/uapi/asm/unistd.h b/tools/arch/arc/include/uapi/asm/unistd.h
> new file mode 100644
> index 000000000000..5eafa1115162
> --- /dev/null
> +++ b/tools/arch/arc/include/uapi/asm/unistd.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (http://www.synopsys.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/******** no-legacy-syscalls-ABI *******/
> +
> +/*
> + * Non-typical guard macro to enable inclusion twice in ARCH sys.c
> + * That is how the Generic syscall wrapper generator works
> + */
> +#if !defined(_UAPI_ASM_ARC_UNISTD_H) || defined(__SYSCALL)

This guard ifdef is not present in existing tools/arch/*/**/unistd.h , nor in the
ones below so I'd suggest just drop it to keep things consistent.
If you still want them, best to call it _TOOLS_UAPI_ASM_ARC_UNISTD_H

> +#define _UAPI_ASM_ARC_UNISTD_H
> +
> +#define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_STAT64
> +#define __ARCH_WANT_SET_GET_RLIMIT
> +#define __ARCH_WANT_SYS_EXECVE
> +#define __ARCH_WANT_SYS_CLONE
> +#define __ARCH_WANT_SYS_VFORK
> +#define __ARCH_WANT_SYS_FORK
> +#define __ARCH_WANT_TIME32_SYSCALLS
> +
> +#define sys_mmap2 sys_mmap_pgoff
> +
> +#include <asm-generic/unistd.h>

> +
> +#define NR_syscalls	__NR_syscalls
> +
> +/* Generic syscall (fs/filesystems.c - lost in asm-generic/unistd.h */
> +#define __NR_sysfs		(__NR_arch_specific_syscall + 3)
> +
> +/* ARC specific syscall */
> +#define __NR_cacheflush		(__NR_arch_specific_syscall + 0)
> +#define __NR_arc_settls		(__NR_arch_specific_syscall + 1)
> +#define __NR_arc_gettls		(__NR_arch_specific_syscall + 2)
> +#define __NR_arc_usr_cmpxchg	(__NR_arch_specific_syscall + 4)
> +
> +__SYSCALL(__NR_cacheflush, sys_cacheflush)
> +__SYSCALL(__NR_arc_settls, sys_arc_settls)
> +__SYSCALL(__NR_arc_gettls, sys_arc_gettls)
> +__SYSCALL(__NR_arc_usr_cmpxchg, sys_arc_usr_cmpxchg)
> +__SYSCALL(__NR_sysfs, sys_sysfs)
> +
> +#undef __SYSCALL
> +
> +#endif
> diff --git a/tools/arch/hexagon/include/uapi/asm/unistd.h b/tools/arch/hexagon/include/uapi/asm/unistd.h
> new file mode 100644
> index 000000000000..432c4db1b623
> --- /dev/null
> +++ b/tools/arch/hexagon/include/uapi/asm/unistd.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * Syscall support for Hexagon
> + *
> + * Copyright (c) 2010-2011, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> + * 02110-1301, USA.
> + */
> +
> +/*
> + *  The kernel pulls this unistd.h in three different ways:
> + *  1.  the "normal" way which gets all the __NR defines
> + *  2.  with __SYSCALL defined to produce function declarations
> + *  3.  with __SYSCALL defined to produce syscall table initialization
> + *  See also:  syscalltab.c
> + */
> +
> +#define sys_mmap2 sys_mmap_pgoff
> +#define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_STAT64
> +#define __ARCH_WANT_SET_GET_RLIMIT
> +#define __ARCH_WANT_SYS_EXECVE
> +#define __ARCH_WANT_SYS_CLONE
> +#define __ARCH_WANT_SYS_VFORK
> +#define __ARCH_WANT_SYS_FORK
> +#define __ARCH_WANT_TIME32_SYSCALLS
> +
> +#include <asm-generic/unistd.h>
> diff --git a/tools/arch/riscv/include/uapi/asm/unistd.h b/tools/arch/riscv/include/uapi/asm/unistd.h
> new file mode 100644
> index 000000000000..0e2eeeb1fd27
> --- /dev/null
> +++ b/tools/arch/riscv/include/uapi/asm/unistd.h
> @@ -0,0 +1,42 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * Copyright (C) 2018 David Abdurachmanov <david.abdurachmanov@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gnu.org_licenses_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=obdUU5ZihUrFi8F2O4JfVYScd7CLKNItF83dHmezlkU&s=qw-VNuV5RBu7T5rL77GOTAKBzZB-zvizjJ3Haik7x9g&e=>.
> + */
> +
> +#ifdef __LP64__
> +#define __ARCH_WANT_NEW_STAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
> +#endif /* __LP64__ */
> +
> +#include <asm-generic/unistd.h>
> +
> +/*
> + * Allows the instruction cache to be flushed from userspace.  Despite RISC-V
> + * having a direct 'fence.i' instruction available to userspace (which we
> + * can't trap!), that's not actually viable when running on Linux because the
> + * kernel might schedule a process on another hart.  There is no way for
> + * userspace to handle this without invoking the kernel (as it doesn't know the
> + * thread->hart mappings), so we've defined a RISC-V specific system call to
> + * flush the instruction cache.
> + *
> + * __NR_riscv_flush_icache is defined to flush the instruction cache over an
> + * address range, with the flush applying to either all threads or just the
> + * caller.  We don't currently do anything with the address range, that's just
> + * in there for forwards compatibility.
> + */
> +#ifndef __NR_riscv_flush_icache
> +#define __NR_riscv_flush_icache (__NR_arch_specific_syscall + 15)
> +#endif
> +__SYSCALL(__NR_riscv_flush_icache, sys_riscv_flush_icache)
>


^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-29 17:23           ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-29 17:23 UTC (permalink / raw)
  To: linux-snps-arc

On 4/26/19 12:35 PM, Arnaldo Carvalho de Melo wrote:
> Em Fri, Apr 26, 2019 at 04:28:34PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Apr 25, 2019 at 06:48:00PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
>>>>> When building perf for ARC (v5.1-rc2) I get the following
>>>>  
>>>>> | In file included from bench/futex-hash.c:26:
>>>>> | bench/futex.h: In function 'futex_wait':
>>>>> | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
>>>>  
>>>>> git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
>>>>> Sync copy of asm-generic/unistd.h with the kernel sources")
>>>> Humm, I have to check why this:
>>>>
>>>> [perfbuilder at quaco ~]$ podman images | grep ARC
>>>> docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
>>>> [perfbuilder at quaco ~]$
>>>>
>>>> isn't catching this... :-\
>>>>
>>>> FROM docker.io/fedora:24
>>>> MAINTAINER Arnaldo Carvalho de Melo <acme at kernel.org>
>>>> ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
>>>> ENV CROSS=arc-linux-
>>>> ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
>>>> RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
>>>> RUN wget https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_foss-2Dfor-2Dsynopsys-2Ddwc-2Darc-2Dprocessors_toolchain_releases_download_arc-2D2017.09-2Drc2_-24-257BSOURCEFILE-257D&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=obdUU5ZihUrFi8F2O4JfVYScd7CLKNItF83dHmezlkU&s=oOPRKzvGneimee7GFXWyqqoVfgvHu-jwSMKPbSqwP5M&e=
>>>> <SNIP>
>>>> COPY rx_and_build.sh /
>>>> ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
>>>> ENV ARCH=arc
>>>> ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
>>>> ENV EXTRA_CFLAGS=-matomic
>>> So, now I have a libnuma crossbuilt in this container that allows me to
>>> build a ARC perf binary linked with zlib and numactl-devel, but only
>>> after I applied the fix below.
>>>
>>> Can you please provide the feature detection header in the build? I.e.
>>> what I have with my ARC cross build container right now, after applying
>>> the patch below is:
>> So, switched from the uCLibc build system to the glibc based one, so
>> that I could get elfutils building (it needs argp that isn't available
>> with uCLibc) I have it reproduced, see below, now I'm testing with the
>> fix, which is to grab the unistd.h files you noticed missing for the
>> arches that are present in tools/arch/, will post results soon
> Yep, now it builds:
>
> /tmp/build/perf/perf: ELF 32-bit LSB executable, *unknown arch 0xc3* version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-arc.so.2, for GNU/Linux 3.9.0, with debug_info, not stripped
>
> With this patch:
>
> commit dd423246b321967eace3f3e0fe73d638050b447c
> Author: Arnaldo Carvalho de Melo <acme at redhat.com>
> Date:   Mon Apr 22 15:21:35 2019 -0300
>
>     WIP
>     
>     Signed-off-by: Arnaldo Carvalho de Melo <acme at redhat.com>
>
> diff --git a/tools/arch/arc/include/uapi/asm/unistd.h b/tools/arch/arc/include/uapi/asm/unistd.h
> new file mode 100644
> index 000000000000..5eafa1115162
> --- /dev/null
> +++ b/tools/arch/arc/include/uapi/asm/unistd.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (http://www.synopsys.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/******** no-legacy-syscalls-ABI *******/
> +
> +/*
> + * Non-typical guard macro to enable inclusion twice in ARCH sys.c
> + * That is how the Generic syscall wrapper generator works
> + */
> +#if !defined(_UAPI_ASM_ARC_UNISTD_H) || defined(__SYSCALL)

This guard ifdef is not present in existing tools/arch/*/**/unistd.h , nor in the
ones below so I'd suggest just drop it to keep things consistent.
If you still want them, best to call it _TOOLS_UAPI_ASM_ARC_UNISTD_H

> +#define _UAPI_ASM_ARC_UNISTD_H
> +
> +#define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_STAT64
> +#define __ARCH_WANT_SET_GET_RLIMIT
> +#define __ARCH_WANT_SYS_EXECVE
> +#define __ARCH_WANT_SYS_CLONE
> +#define __ARCH_WANT_SYS_VFORK
> +#define __ARCH_WANT_SYS_FORK
> +#define __ARCH_WANT_TIME32_SYSCALLS
> +
> +#define sys_mmap2 sys_mmap_pgoff
> +
> +#include <asm-generic/unistd.h>

> +
> +#define NR_syscalls	__NR_syscalls
> +
> +/* Generic syscall (fs/filesystems.c - lost in asm-generic/unistd.h */
> +#define __NR_sysfs		(__NR_arch_specific_syscall + 3)
> +
> +/* ARC specific syscall */
> +#define __NR_cacheflush		(__NR_arch_specific_syscall + 0)
> +#define __NR_arc_settls		(__NR_arch_specific_syscall + 1)
> +#define __NR_arc_gettls		(__NR_arch_specific_syscall + 2)
> +#define __NR_arc_usr_cmpxchg	(__NR_arch_specific_syscall + 4)
> +
> +__SYSCALL(__NR_cacheflush, sys_cacheflush)
> +__SYSCALL(__NR_arc_settls, sys_arc_settls)
> +__SYSCALL(__NR_arc_gettls, sys_arc_gettls)
> +__SYSCALL(__NR_arc_usr_cmpxchg, sys_arc_usr_cmpxchg)
> +__SYSCALL(__NR_sysfs, sys_sysfs)
> +
> +#undef __SYSCALL
> +
> +#endif
> diff --git a/tools/arch/hexagon/include/uapi/asm/unistd.h b/tools/arch/hexagon/include/uapi/asm/unistd.h
> new file mode 100644
> index 000000000000..432c4db1b623
> --- /dev/null
> +++ b/tools/arch/hexagon/include/uapi/asm/unistd.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * Syscall support for Hexagon
> + *
> + * Copyright (c) 2010-2011, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> + * 02110-1301, USA.
> + */
> +
> +/*
> + *  The kernel pulls this unistd.h in three different ways:
> + *  1.  the "normal" way which gets all the __NR defines
> + *  2.  with __SYSCALL defined to produce function declarations
> + *  3.  with __SYSCALL defined to produce syscall table initialization
> + *  See also:  syscalltab.c
> + */
> +
> +#define sys_mmap2 sys_mmap_pgoff
> +#define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_STAT64
> +#define __ARCH_WANT_SET_GET_RLIMIT
> +#define __ARCH_WANT_SYS_EXECVE
> +#define __ARCH_WANT_SYS_CLONE
> +#define __ARCH_WANT_SYS_VFORK
> +#define __ARCH_WANT_SYS_FORK
> +#define __ARCH_WANT_TIME32_SYSCALLS
> +
> +#include <asm-generic/unistd.h>
> diff --git a/tools/arch/riscv/include/uapi/asm/unistd.h b/tools/arch/riscv/include/uapi/asm/unistd.h
> new file mode 100644
> index 000000000000..0e2eeeb1fd27
> --- /dev/null
> +++ b/tools/arch/riscv/include/uapi/asm/unistd.h
> @@ -0,0 +1,42 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * Copyright (C) 2018 David Abdurachmanov <david.abdurachmanov at gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gnu.org_licenses_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=obdUU5ZihUrFi8F2O4JfVYScd7CLKNItF83dHmezlkU&s=qw-VNuV5RBu7T5rL77GOTAKBzZB-zvizjJ3Haik7x9g&e=>.
> + */
> +
> +#ifdef __LP64__
> +#define __ARCH_WANT_NEW_STAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
> +#endif /* __LP64__ */
> +
> +#include <asm-generic/unistd.h>
> +
> +/*
> + * Allows the instruction cache to be flushed from userspace.  Despite RISC-V
> + * having a direct 'fence.i' instruction available to userspace (which we
> + * can't trap!), that's not actually viable when running on Linux because the
> + * kernel might schedule a process on another hart.  There is no way for
> + * userspace to handle this without invoking the kernel (as it doesn't know the
> + * thread->hart mappings), so we've defined a RISC-V specific system call to
> + * flush the instruction cache.
> + *
> + * __NR_riscv_flush_icache is defined to flush the instruction cache over an
> + * address range, with the flush applying to either all threads or just the
> + * caller.  We don't currently do anything with the address range, that's just
> + * in there for forwards compatibility.
> + */
> +#ifndef __NR_riscv_flush_icache
> +#define __NR_riscv_flush_icache (__NR_arch_specific_syscall + 15)
> +#endif
> +__SYSCALL(__NR_riscv_flush_icache, sys_riscv_flush_icache)
>

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-29 17:14       ` Vineet Gupta
  (?)
@ 2019-04-30  1:18         ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-30  1:18 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnaldo Carvalho de Melo, linux-perf-users,
	Arnaldo Carvalho de Melo, lkml, arcml, Arnd Bergmann, Jiri Olsa,
	Namhyung Kim

Em Mon, Apr 29, 2019 at 05:14:54PM +0000, Vineet Gupta escreveu:
> On 4/25/19 2:48 PM, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> >>> When building perf for ARC (v5.1-rc2) I get the following
> >>  
> >>> | In file included from bench/futex-hash.c:26:
> >>> | bench/futex.h: In function 'futex_wait':
> >>> | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
> >>  
> >>> git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> >>> Sync copy of asm-generic/unistd.h with the kernel sources")
> >> Humm, I have to check why this:
> >>
> >> [perfbuilder@quaco ~]$ podman images | grep ARC
> >> docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> >> [perfbuilder@quaco ~]$
> >>
> >> isn't catching this... :-\
> >>
> >> FROM docker.io/fedora:24
> >> MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> >> ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> >> ENV CROSS=arc-linux-
> >> ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> >> RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> >> RUN wget https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_foss-2Dfor-2Dsynopsys-2Ddwc-2Darc-2Dprocessors_toolchain_releases_download_arc-2D2017.09-2Drc2_-24-257BSOURCEFILE-257D&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=HjtufCLozrW47pS5C2YH3safLHQE7eEtmHFZsSWrz1M&s=29g4oKvGuYcLgheCUvZh3wojhhljivpLd8aj7Ur4sKQ&e=
> >> <SNIP>
> >> COPY rx_and_build.sh /
> >> ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> >> ENV ARCH=arc
> >> ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> >> ENV EXTRA_CFLAGS=-matomic
> > So, now I have a libnuma crossbuilt in this container that allows me to
> > build a ARC perf binary linked with zlib and numactl-devel, but only
> > after I applied the fix below.
> >
> > Can you please provide the feature detection header in the build? I.e.
> > what I have with my ARC cross build container right now, after applying
> > the patch below is:
> >
> > [perfbuilder@60d5802468f6 perf]$ make $EXTRA_MAKE_ARGS ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE EXTRA_CFLAGS="$EXTRA_CFLAGS" -C /git/perf/tools/perf O=/tmp/build/perf
> > make: Entering directory '/git/perf/tools/perf'
> >   BUILD:   Doing 'make -j8' parallel build
> > sh: line 0: command: -c: invalid option
> > command: usage: command [-pVv] command [arg ...]
> >
> > Auto-detecting system features:
> > ...                         dwarf: [ OFF ]
> > ...            dwarf_getlocations: [ OFF ]
> > ...                         glibc: [ on  ]
> 
> Not related to current issue, this run uses a uClibc toolchain and yet it is
> detecting glibc - doesn't seem right to me.

Ok, I'll improve that, I think it just tries to detect a libc, yeah,
see:

[acme@quaco linux]$ cat tools/build/feature/test-glibc.c
// SPDX-License-Identifier: GPL-2.0
#include <stdlib.h>

#if !defined(__UCLIBC__)
#include <gnu/libc-version.h>
#else
#define XSTR(s) STR(s)
#define STR(s) #s
#endif

int main(void)
{
#if !defined(__UCLIBC__)
	const char *version = gnu_get_libc_version();
#else
	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
#endif

	return (long)version;
}
[acme@quaco linux]$

[perfbuilder@59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
[perfbuilder@59ca4b424ded /]$

Isn't that part of uClibc?
 
> > ...                          gtk2: [ OFF ]
> > ...                      libaudit: [ OFF ]
> > ...                        libbfd: [ OFF ]
> > ...                        libelf: [ OFF ]
> > ...                       libnuma: [ on  ]
> 
> Wondering why that is - for me numa is off - even when using a glibc toolchain.
> 
> > ...        numa_num_possible_cpus: [ on  ]
> > ...                       libperl: [ OFF ]
> > ...                     libpython: [ OFF ]
> > ...                      libslang: [ OFF ]
> > ...                     libcrypto: [ OFF ]
> > ...                     libunwind: [ OFF ]
> > ...            libdw-dwarf-unwind: [ OFF ]
> > ...                          zlib: [ OFF ]
> > ...                          lzma: [ OFF ]
> > ...                     get_cpuid: [ OFF ]
> > ...                           bpf: [ on  ]
> > ...                        libaio: [ OFF ]
> > ...        disassembler-four-args: [ OFF ]
> >
> >
> 
> For my glibc toolchain, here's the feature detection output
> 
> Auto-detecting system features:
> ...                         dwarf: [ on  ]
> ...            dwarf_getlocations: [ OFF ]
> ...                         glibc: [ on  ]
> ...                          gtk2: [ OFF ]
> ...                      libaudit: [ OFF ]
> ...                        libbfd: [ OFF ]
> ...                        libelf: [ on  ]
> ...                       libnuma: [ OFF ]
> ...        numa_num_possible_cpus: [ OFF ]
> ...                       libperl: [ OFF ]
> ...                     libpython: [ OFF ]
> ...                      libslang: [ OFF ]
> ...                     libcrypto: [ OFF ]
> ...                     libunwind: [ OFF ]
> ...            libdw-dwarf-unwind: [ OFF ]
> ...                          zlib: [ OFF ]
> ...                          lzma: [ OFF ]
> ...                     get_cpuid: [ OFF ]
> ...                           bpf: [ on  ]
> ...                        libaio: [ on  ]
> ...        disassembler-four-args: [ OFF ]
> 
> 

-- 

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
@ 2019-04-30  1:18         ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-30  1:18 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnaldo Carvalho de Melo, Arnd Bergmann,
	Arnaldo Carvalho de Melo, lkml, linux-perf-users, Jiri Olsa,
	Namhyung Kim, arcml

Em Mon, Apr 29, 2019 at 05:14:54PM +0000, Vineet Gupta escreveu:
> On 4/25/19 2:48 PM, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> >>> When building perf for ARC (v5.1-rc2) I get the following
> >>  
> >>> | In file included from bench/futex-hash.c:26:
> >>> | bench/futex.h: In function 'futex_wait':
> >>> | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
> >>  
> >>> git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> >>> Sync copy of asm-generic/unistd.h with the kernel sources")
> >> Humm, I have to check why this:
> >>
> >> [perfbuilder@quaco ~]$ podman images | grep ARC
> >> docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> >> [perfbuilder@quaco ~]$
> >>
> >> isn't catching this... :-\
> >>
> >> FROM docker.io/fedora:24
> >> MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> >> ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> >> ENV CROSS=arc-linux-
> >> ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> >> RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> >> RUN wget https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_foss-2Dfor-2Dsynopsys-2Ddwc-2Darc-2Dprocessors_toolchain_releases_download_arc-2D2017.09-2Drc2_-24-257BSOURCEFILE-257D&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=HjtufCLozrW47pS5C2YH3safLHQE7eEtmHFZsSWrz1M&s=29g4oKvGuYcLgheCUvZh3wojhhljivpLd8aj7Ur4sKQ&e=
> >> <SNIP>
> >> COPY rx_and_build.sh /
> >> ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> >> ENV ARCH=arc
> >> ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> >> ENV EXTRA_CFLAGS=-matomic
> > So, now I have a libnuma crossbuilt in this container that allows me to
> > build a ARC perf binary linked with zlib and numactl-devel, but only
> > after I applied the fix below.
> >
> > Can you please provide the feature detection header in the build? I.e.
> > what I have with my ARC cross build container right now, after applying
> > the patch below is:
> >
> > [perfbuilder@60d5802468f6 perf]$ make $EXTRA_MAKE_ARGS ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE EXTRA_CFLAGS="$EXTRA_CFLAGS" -C /git/perf/tools/perf O=/tmp/build/perf
> > make: Entering directory '/git/perf/tools/perf'
> >   BUILD:   Doing 'make -j8' parallel build
> > sh: line 0: command: -c: invalid option
> > command: usage: command [-pVv] command [arg ...]
> >
> > Auto-detecting system features:
> > ...                         dwarf: [ OFF ]
> > ...            dwarf_getlocations: [ OFF ]
> > ...                         glibc: [ on  ]
> 
> Not related to current issue, this run uses a uClibc toolchain and yet it is
> detecting glibc - doesn't seem right to me.

Ok, I'll improve that, I think it just tries to detect a libc, yeah,
see:

[acme@quaco linux]$ cat tools/build/feature/test-glibc.c
// SPDX-License-Identifier: GPL-2.0
#include <stdlib.h>

#if !defined(__UCLIBC__)
#include <gnu/libc-version.h>
#else
#define XSTR(s) STR(s)
#define STR(s) #s
#endif

int main(void)
{
#if !defined(__UCLIBC__)
	const char *version = gnu_get_libc_version();
#else
	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
#endif

	return (long)version;
}
[acme@quaco linux]$

[perfbuilder@59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
[perfbuilder@59ca4b424ded /]$

Isn't that part of uClibc?
 
> > ...                          gtk2: [ OFF ]
> > ...                      libaudit: [ OFF ]
> > ...                        libbfd: [ OFF ]
> > ...                        libelf: [ OFF ]
> > ...                       libnuma: [ on  ]
> 
> Wondering why that is - for me numa is off - even when using a glibc toolchain.
> 
> > ...        numa_num_possible_cpus: [ on  ]
> > ...                       libperl: [ OFF ]
> > ...                     libpython: [ OFF ]
> > ...                      libslang: [ OFF ]
> > ...                     libcrypto: [ OFF ]
> > ...                     libunwind: [ OFF ]
> > ...            libdw-dwarf-unwind: [ OFF ]
> > ...                          zlib: [ OFF ]
> > ...                          lzma: [ OFF ]
> > ...                     get_cpuid: [ OFF ]
> > ...                           bpf: [ on  ]
> > ...                        libaio: [ OFF ]
> > ...        disassembler-four-args: [ OFF ]
> >
> >
> 
> For my glibc toolchain, here's the feature detection output
> 
> Auto-detecting system features:
> ...                         dwarf: [ on  ]
> ...            dwarf_getlocations: [ OFF ]
> ...                         glibc: [ on  ]
> ...                          gtk2: [ OFF ]
> ...                      libaudit: [ OFF ]
> ...                        libbfd: [ OFF ]
> ...                        libelf: [ on  ]
> ...                       libnuma: [ OFF ]
> ...        numa_num_possible_cpus: [ OFF ]
> ...                       libperl: [ OFF ]
> ...                     libpython: [ OFF ]
> ...                      libslang: [ OFF ]
> ...                     libcrypto: [ OFF ]
> ...                     libunwind: [ OFF ]
> ...            libdw-dwarf-unwind: [ OFF ]
> ...                          zlib: [ OFF ]
> ...                          lzma: [ OFF ]
> ...                     get_cpuid: [ OFF ]
> ...                           bpf: [ on  ]
> ...                        libaio: [ on  ]
> ...        disassembler-four-args: [ OFF ]
> 
> 

-- 

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-30  1:18         ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-04-30  1:18 UTC (permalink / raw)
  To: linux-snps-arc

Em Mon, Apr 29, 2019 at 05:14:54PM +0000, Vineet Gupta escreveu:
> On 4/25/19 2:48 PM, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Apr 22, 2019 at 12:20:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Fri, Apr 19, 2019 at 04:32:58PM -0700, Vineet Gupta escreveu:
> >>> When building perf for ARC (v5.1-rc2) I get the following
> >>  
> >>> | In file included from bench/futex-hash.c:26:
> >>> | bench/futex.h: In function 'futex_wait':
> >>> | bench/futex.h:37:10: error: 'SYS_futex' undeclared (first use in this function);
> >>  
> >>> git bisect led to 1a787fc5ba18ac767e635c58d06a0b46876184e3 ("tools headers uapi:
> >>> Sync copy of asm-generic/unistd.h with the kernel sources")
> >> Humm, I have to check why this:
> >>
> >> [perfbuilder at quaco ~]$ podman images | grep ARC
> >> docker.io/acmel/linux-perf-tools-build-fedora                24-x-ARC-uClibc          4c259582a8e6   5 weeks ago      846 MB
> >> [perfbuilder at quaco ~]$
> >>
> >> isn't catching this... :-\
> >>
> >> FROM docker.io/fedora:24
> >> MAINTAINER Arnaldo Carvalho de Melo <acme at kernel.org>
> >> ENV TOOLCHAIN=arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install
> >> ENV CROSS=arc-linux-
> >> ENV SOURCEFILE=${TOOLCHAIN}.tar.gz
> >> RUN dnf -y install make flex bison binutils gcc wget tar bzip2 bc findutils xz
> >> RUN wget https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_foss-2Dfor-2Dsynopsys-2Ddwc-2Darc-2Dprocessors_toolchain_releases_download_arc-2D2017.09-2Drc2_-24-257BSOURCEFILE-257D&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=HjtufCLozrW47pS5C2YH3safLHQE7eEtmHFZsSWrz1M&s=29g4oKvGuYcLgheCUvZh3wojhhljivpLd8aj7Ur4sKQ&e=
> >> <SNIP>
> >> COPY rx_and_build.sh /
> >> ENV EXTRA_MAKE_ARGS=NO_LIBBPF=1
> >> ENV ARCH=arc
> >> ENV CROSS_COMPILE=/${TOOLCHAIN}/bin/${CROSS}
> >> ENV EXTRA_CFLAGS=-matomic
> > So, now I have a libnuma crossbuilt in this container that allows me to
> > build a ARC perf binary linked with zlib and numactl-devel, but only
> > after I applied the fix below.
> >
> > Can you please provide the feature detection header in the build? I.e.
> > what I have with my ARC cross build container right now, after applying
> > the patch below is:
> >
> > [perfbuilder at 60d5802468f6 perf]$ make $EXTRA_MAKE_ARGS ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE EXTRA_CFLAGS="$EXTRA_CFLAGS" -C /git/perf/tools/perf O=/tmp/build/perf
> > make: Entering directory '/git/perf/tools/perf'
> >   BUILD:   Doing 'make -j8' parallel build
> > sh: line 0: command: -c: invalid option
> > command: usage: command [-pVv] command [arg ...]
> >
> > Auto-detecting system features:
> > ...                         dwarf: [ OFF ]
> > ...            dwarf_getlocations: [ OFF ]
> > ...                         glibc: [ on  ]
> 
> Not related to current issue, this run uses a uClibc toolchain and yet it is
> detecting glibc - doesn't seem right to me.

Ok, I'll improve that, I think it just tries to detect a libc, yeah,
see:

[acme at quaco linux]$ cat tools/build/feature/test-glibc.c
// SPDX-License-Identifier: GPL-2.0
#include <stdlib.h>

#if !defined(__UCLIBC__)
#include <gnu/libc-version.h>
#else
#define XSTR(s) STR(s)
#define STR(s) #s
#endif

int main(void)
{
#if !defined(__UCLIBC__)
	const char *version = gnu_get_libc_version();
#else
	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
#endif

	return (long)version;
}
[acme at quaco linux]$

[perfbuilder at 59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
[perfbuilder at 59ca4b424ded /]$

Isn't that part of uClibc?
 
> > ...                          gtk2: [ OFF ]
> > ...                      libaudit: [ OFF ]
> > ...                        libbfd: [ OFF ]
> > ...                        libelf: [ OFF ]
> > ...                       libnuma: [ on  ]
> 
> Wondering why that is - for me numa is off - even when using a glibc toolchain.
> 
> > ...        numa_num_possible_cpus: [ on  ]
> > ...                       libperl: [ OFF ]
> > ...                     libpython: [ OFF ]
> > ...                      libslang: [ OFF ]
> > ...                     libcrypto: [ OFF ]
> > ...                     libunwind: [ OFF ]
> > ...            libdw-dwarf-unwind: [ OFF ]
> > ...                          zlib: [ OFF ]
> > ...                          lzma: [ OFF ]
> > ...                     get_cpuid: [ OFF ]
> > ...                           bpf: [ on  ]
> > ...                        libaio: [ OFF ]
> > ...        disassembler-four-args: [ OFF ]
> >
> >
> 
> For my glibc toolchain, here's the feature detection output
> 
> Auto-detecting system features:
> ...                         dwarf: [ on  ]
> ...            dwarf_getlocations: [ OFF ]
> ...                         glibc: [ on  ]
> ...                          gtk2: [ OFF ]
> ...                      libaudit: [ OFF ]
> ...                        libbfd: [ OFF ]
> ...                        libelf: [ on  ]
> ...                       libnuma: [ OFF ]
> ...        numa_num_possible_cpus: [ OFF ]
> ...                       libperl: [ OFF ]
> ...                     libpython: [ OFF ]
> ...                      libslang: [ OFF ]
> ...                     libcrypto: [ OFF ]
> ...                     libunwind: [ OFF ]
> ...            libdw-dwarf-unwind: [ OFF ]
> ...                          zlib: [ OFF ]
> ...                          lzma: [ OFF ]
> ...                     get_cpuid: [ OFF ]
> ...                           bpf: [ on  ]
> ...                        libaio: [ on  ]
> ...        disassembler-four-args: [ OFF ]
> 
> 

-- 

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
  2019-04-30  1:18         ` Arnaldo Carvalho de Melo
@ 2019-04-30 15:53           ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-30 15:53 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: devel, linux-perf-users, Arnaldo Carvalho de Melo, lkml, arcml,
	Arnd Bergmann, Jiri Olsa, Namhyung Kim, Rich Felker

On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
>>> Auto-detecting system features:
>>> ...                         dwarf: [ OFF ]
>>> ...            dwarf_getlocations: [ OFF ]
>>> ...                         glibc: [ on  ]
>> Not related to current issue, this run uses a uClibc toolchain and yet it is
>> detecting glibc - doesn't seem right to me.
> Ok, I'll improve that, I think it just tries to detect a libc, yeah,
> see:
>
> [acme@quaco linux]$ cat tools/build/feature/test-glibc.c
> // SPDX-License-Identifier: GPL-2.0
> #include <stdlib.h>
>
> #if !defined(__UCLIBC__)
> #include <gnu/libc-version.h>
> #else
> #define XSTR(s) STR(s)
> #define STR(s) #s
> #endif
>
> int main(void)
> {
> #if !defined(__UCLIBC__)
> 	const char *version = gnu_get_libc_version();
> #else
> 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> #endif
>
> 	return (long)version;
> }
> [acme@quaco linux]$
>
> [perfbuilder@59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
> [perfbuilder@59ca4b424ded /]$
>
> Isn't that part of uClibc?

Right you are. Per the big fat comment right above that code, this gross hack in
uclibc is unavoidable as applications tend to rely on that define.
So a better fix would be to check for various !GLIBC libs explicitly.

#ifdef __UCLIBC__

#elseif defined __MUSL__

...

Not pretty from app usage pov, but that seems to be the only sane way of doing it.

-Vineet

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
@ 2019-04-30 15:53           ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-30 15:53 UTC (permalink / raw)
  To: linux-snps-arc

On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
>>> Auto-detecting system features:
>>> ...                         dwarf: [ OFF ]
>>> ...            dwarf_getlocations: [ OFF ]
>>> ...                         glibc: [ on  ]
>> Not related to current issue, this run uses a uClibc toolchain and yet it is
>> detecting glibc - doesn't seem right to me.
> Ok, I'll improve that, I think it just tries to detect a libc, yeah,
> see:
>
> [acme at quaco linux]$ cat tools/build/feature/test-glibc.c
> // SPDX-License-Identifier: GPL-2.0
> #include <stdlib.h>
>
> #if !defined(__UCLIBC__)
> #include <gnu/libc-version.h>
> #else
> #define XSTR(s) STR(s)
> #define STR(s) #s
> #endif
>
> int main(void)
> {
> #if !defined(__UCLIBC__)
> 	const char *version = gnu_get_libc_version();
> #else
> 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> #endif
>
> 	return (long)version;
> }
> [acme at quaco linux]$
>
> [perfbuilder at 59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
> [perfbuilder at 59ca4b424ded /]$
>
> Isn't that part of uClibc?

Right you are. Per the big fat comment right above that code, this gross hack in
uclibc is unavoidable as applications tend to rely on that define.
So a better fix would be to check for various !GLIBC libs explicitly.

#ifdef __UCLIBC__

#elseif defined __MUSL__

...

Not pretty from app usage pov, but that seems to be the only sane way of doing it.

-Vineet

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-29 17:17     ` Vineet Gupta
@ 2019-04-30 16:12       ` Arnd Bergmann
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnd Bergmann @ 2019-04-30 16:12 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnaldo Carvalho de Melo, Arnaldo Carvalho de Melo, lkml,
	linux-perf-users, Jiri Olsa, Namhyung Kim, arcml

On Mon, Apr 29, 2019 at 7:17 PM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
>
> On 4/22/19 8:31 AM, Arnaldo Carvalho de Melo wrote:
> >> A quick fix for ARC will be to create our own version but I presume all existing
> >> arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
> >> send out a patch for ARC.
> >>
> >> P.S. Why do we need the unistd.h duplication in tools directory, given it could
> >> have used the in-tree unistd headers directly ?
> > I have to write down the explanation and have it in a file, but we can't
> > use anything in the kernel from outside tools/ to avoid adding a burden
> > to kernel developers that would then have to make sure that the changes
> > that they make outside tools/ don't break things living there.
>
> That is a sound guiding principle in general but I don't agree here. unistd is
> backbone of kernel user interface it has to work and can't possibly be broken even
> when kernel devs add a new syscall is added or condition-alize existing one. So
> adding a copy - and deferring the propagation of in-kernel unistd to usersapce
> won't necessarily help with anything and it just adds the burden of keeping them
> in sync. Granted we won't necessarily need all the bleeding edge (new syscall
> updates) into that header, its still more work.

I think more importantly, it seems completely broken to sync a file from
asm-generic but not the arch specific file that includes it.

The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
missed all the other architectures changed in c8ce48f06503 and the
related commits.

      Arnd

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-04-30 16:12       ` Arnd Bergmann
  0 siblings, 0 replies; 55+ messages in thread
From: Arnd Bergmann @ 2019-04-30 16:12 UTC (permalink / raw)
  To: linux-snps-arc

On Mon, Apr 29, 2019@7:17 PM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
>
> On 4/22/19 8:31 AM, Arnaldo Carvalho de Melo wrote:
> >> A quick fix for ARC will be to create our own version but I presume all existing
> >> arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
> >> send out a patch for ARC.
> >>
> >> P.S. Why do we need the unistd.h duplication in tools directory, given it could
> >> have used the in-tree unistd headers directly ?
> > I have to write down the explanation and have it in a file, but we can't
> > use anything in the kernel from outside tools/ to avoid adding a burden
> > to kernel developers that would then have to make sure that the changes
> > that they make outside tools/ don't break things living there.
>
> That is a sound guiding principle in general but I don't agree here. unistd is
> backbone of kernel user interface it has to work and can't possibly be broken even
> when kernel devs add a new syscall is added or condition-alize existing one. So
> adding a copy - and deferring the propagation of in-kernel unistd to usersapce
> won't necessarily help with anything and it just adds the burden of keeping them
> in sync. Granted we won't necessarily need all the bleeding edge (new syscall
> updates) into that header, its still more work.

I think more importantly, it seems completely broken to sync a file from
asm-generic but not the arch specific file that includes it.

The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
missed all the other architectures changed in c8ce48f06503 and the
related commits.

      Arnd

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
  2019-04-30 15:53           ` Vineet Gupta
@ 2019-04-30 17:04             ` Rich Felker
  -1 siblings, 0 replies; 55+ messages in thread
From: Rich Felker @ 2019-04-30 17:04 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnaldo Carvalho de Melo, devel, linux-perf-users,
	Arnaldo Carvalho de Melo, lkml, arcml, Arnd Bergmann, Jiri Olsa,
	Namhyung Kim

On Tue, Apr 30, 2019 at 03:53:18PM +0000, Vineet Gupta wrote:
> On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
> >>> Auto-detecting system features:
> >>> ...                         dwarf: [ OFF ]
> >>> ...            dwarf_getlocations: [ OFF ]
> >>> ...                         glibc: [ on  ]
> >> Not related to current issue, this run uses a uClibc toolchain and yet it is
> >> detecting glibc - doesn't seem right to me.
> > Ok, I'll improve that, I think it just tries to detect a libc, yeah,
> > see:
> >
> > [acme@quaco linux]$ cat tools/build/feature/test-glibc.c
> > // SPDX-License-Identifier: GPL-2.0
> > #include <stdlib.h>
> >
> > #if !defined(__UCLIBC__)
> > #include <gnu/libc-version.h>
> > #else
> > #define XSTR(s) STR(s)
> > #define STR(s) #s
> > #endif
> >
> > int main(void)
> > {
> > #if !defined(__UCLIBC__)
> > 	const char *version = gnu_get_libc_version();
> > #else
> > 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> > #endif
> >
> > 	return (long)version;
> > }
> > [acme@quaco linux]$
> >
> > [perfbuilder@59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
> > /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
> > /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
> > /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
> > [perfbuilder@59ca4b424ded /]$
> >
> > Isn't that part of uClibc?
> 
> Right you are. Per the big fat comment right above that code, this gross hack in
> uclibc is unavoidable as applications tend to rely on that define.
> So a better fix would be to check for various !GLIBC libs explicitly.
> 
> #ifdef __UCLIBC__
> 
> #elseif defined __MUSL__
> 
> ....
> 
> Not pretty from app usage pov, but that seems to be the only sane way of doing it.

What are you trying to achieve? I was just CC'd and I'm missing the
context.

Rich

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
@ 2019-04-30 17:04             ` Rich Felker
  0 siblings, 0 replies; 55+ messages in thread
From: Rich Felker @ 2019-04-30 17:04 UTC (permalink / raw)
  To: linux-snps-arc

On Tue, Apr 30, 2019@03:53:18PM +0000, Vineet Gupta wrote:
> On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
> >>> Auto-detecting system features:
> >>> ...                         dwarf: [ OFF ]
> >>> ...            dwarf_getlocations: [ OFF ]
> >>> ...                         glibc: [ on  ]
> >> Not related to current issue, this run uses a uClibc toolchain and yet it is
> >> detecting glibc - doesn't seem right to me.
> > Ok, I'll improve that, I think it just tries to detect a libc, yeah,
> > see:
> >
> > [acme at quaco linux]$ cat tools/build/feature/test-glibc.c
> > // SPDX-License-Identifier: GPL-2.0
> > #include <stdlib.h>
> >
> > #if !defined(__UCLIBC__)
> > #include <gnu/libc-version.h>
> > #else
> > #define XSTR(s) STR(s)
> > #define STR(s) #s
> > #endif
> >
> > int main(void)
> > {
> > #if !defined(__UCLIBC__)
> > 	const char *version = gnu_get_libc_version();
> > #else
> > 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> > #endif
> >
> > 	return (long)version;
> > }
> > [acme at quaco linux]$
> >
> > [perfbuilder at 59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
> > /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
> > /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
> > /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
> > [perfbuilder at 59ca4b424ded /]$
> >
> > Isn't that part of uClibc?
> 
> Right you are. Per the big fat comment right above that code, this gross hack in
> uclibc is unavoidable as applications tend to rely on that define.
> So a better fix would be to check for various !GLIBC libs explicitly.
> 
> #ifdef __UCLIBC__
> 
> #elseif defined __MUSL__
> 
> ....
> 
> Not pretty from app usage pov, but that seems to be the only sane way of doing it.

What are you trying to achieve? I was just CC'd and I'm missing the
context.

Rich

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
  2019-04-30 17:04             ` Rich Felker
@ 2019-04-30 17:13               ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-30 17:13 UTC (permalink / raw)
  To: Rich Felker
  Cc: Arnaldo Carvalho de Melo, devel, linux-perf-users,
	Arnaldo Carvalho de Melo, lkml, arcml, Arnd Bergmann, Jiri Olsa,
	Namhyung Kim

On 4/30/19 10:04 AM, Rich Felker wrote:
> On Tue, Apr 30, 2019 at 03:53:18PM +0000, Vineet Gupta wrote:
>> On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
>>>>> Auto-detecting system features:
>>>>> ...                         dwarf: [ OFF ]
>>>>> ...            dwarf_getlocations: [ OFF ]
>>>>> ...                         glibc: [ on  ]
>>>> Not related to current issue, this run uses a uClibc toolchain and yet it is
>>>> detecting glibc - doesn't seem right to me.
>>> Ok, I'll improve that, I think it just tries to detect a libc, yeah,
>>> see:
>>>
>>> [acme@quaco linux]$ cat tools/build/feature/test-glibc.c
>>> // SPDX-License-Identifier: GPL-2.0
>>> #include <stdlib.h>
>>>
>>> #if !defined(__UCLIBC__)
>>> #include <gnu/libc-version.h>
>>> #else
>>> #define XSTR(s) STR(s)
>>> #define STR(s) #s
>>> #endif
>>>
>>> int main(void)
>>> {
>>> #if !defined(__UCLIBC__)
>>> 	const char *version = gnu_get_libc_version();
>>> #else
>>> 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
>>> #endif
>>>
>>> 	return (long)version;
>>> }
>>> [acme@quaco linux]$
>>>
>>> [perfbuilder@59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
>>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
>>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
>>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
>>> [perfbuilder@59ca4b424ded /]$
>>>
>>> Isn't that part of uClibc?
>>
>> Right you are. Per the big fat comment right above that code, this gross hack in
>> uclibc is unavoidable as applications tend to rely on that define.
>> So a better fix would be to check for various !GLIBC libs explicitly.
>>
>> #ifdef __UCLIBC__
>>
>> #elseif defined __MUSL__
>>
>> ....
>>
>> Not pretty from app usage pov, but that seems to be the only sane way of doing it.
> 
> What are you trying to achieve? I was just CC'd and I'm missing the
> context.

Sorry I added you as a subject matter expert but didn't provide enough context.

The original issue [1] was perf failing to build on ARC due to perf tools needing
a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
libc variaint in perf tools where despite uClibc tools, glibc is declared to be
detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
not sufficient (and probably not the right interface to begin wtih) to ensure glibc.

[1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
[2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
@ 2019-04-30 17:13               ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-04-30 17:13 UTC (permalink / raw)
  To: linux-snps-arc

On 4/30/19 10:04 AM, Rich Felker wrote:
> On Tue, Apr 30, 2019@03:53:18PM +0000, Vineet Gupta wrote:
>> On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
>>>>> Auto-detecting system features:
>>>>> ...                         dwarf: [ OFF ]
>>>>> ...            dwarf_getlocations: [ OFF ]
>>>>> ...                         glibc: [ on  ]
>>>> Not related to current issue, this run uses a uClibc toolchain and yet it is
>>>> detecting glibc - doesn't seem right to me.
>>> Ok, I'll improve that, I think it just tries to detect a libc, yeah,
>>> see:
>>>
>>> [acme at quaco linux]$ cat tools/build/feature/test-glibc.c
>>> // SPDX-License-Identifier: GPL-2.0
>>> #include <stdlib.h>
>>>
>>> #if !defined(__UCLIBC__)
>>> #include <gnu/libc-version.h>
>>> #else
>>> #define XSTR(s) STR(s)
>>> #define STR(s) #s
>>> #endif
>>>
>>> int main(void)
>>> {
>>> #if !defined(__UCLIBC__)
>>> 	const char *version = gnu_get_libc_version();
>>> #else
>>> 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
>>> #endif
>>>
>>> 	return (long)version;
>>> }
>>> [acme at quaco linux]$
>>>
>>> [perfbuilder at 59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
>>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
>>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
>>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
>>> [perfbuilder at 59ca4b424ded /]$
>>>
>>> Isn't that part of uClibc?
>>
>> Right you are. Per the big fat comment right above that code, this gross hack in
>> uclibc is unavoidable as applications tend to rely on that define.
>> So a better fix would be to check for various !GLIBC libs explicitly.
>>
>> #ifdef __UCLIBC__
>>
>> #elseif defined __MUSL__
>>
>> ....
>>
>> Not pretty from app usage pov, but that seems to be the only sane way of doing it.
> 
> What are you trying to achieve? I was just CC'd and I'm missing the
> context.

Sorry I added you as a subject matter expert but didn't provide enough context.

The original issue [1] was perf failing to build on ARC due to perf tools needing
a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
libc variaint in perf tools where despite uClibc tools, glibc is declared to be
detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
not sufficient (and probably not the right interface to begin wtih) to ensure glibc.

[1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
[2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
  2019-04-30 17:13               ` Vineet Gupta
@ 2019-05-01  3:12                 ` Rich Felker
  -1 siblings, 0 replies; 55+ messages in thread
From: Rich Felker @ 2019-05-01  3:12 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnaldo Carvalho de Melo, devel, linux-perf-users,
	Arnaldo Carvalho de Melo, lkml, arcml, Arnd Bergmann, Jiri Olsa,
	Namhyung Kim

On Tue, Apr 30, 2019 at 10:13:40AM -0700, Vineet Gupta wrote:
> On 4/30/19 10:04 AM, Rich Felker wrote:
> > On Tue, Apr 30, 2019 at 03:53:18PM +0000, Vineet Gupta wrote:
> >> On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
> >>>>> Auto-detecting system features:
> >>>>> ...                         dwarf: [ OFF ]
> >>>>> ...            dwarf_getlocations: [ OFF ]
> >>>>> ...                         glibc: [ on  ]
> >>>> Not related to current issue, this run uses a uClibc toolchain and yet it is
> >>>> detecting glibc - doesn't seem right to me.
> >>> Ok, I'll improve that, I think it just tries to detect a libc, yeah,
> >>> see:
> >>>
> >>> [acme@quaco linux]$ cat tools/build/feature/test-glibc.c
> >>> // SPDX-License-Identifier: GPL-2.0
> >>> #include <stdlib.h>
> >>>
> >>> #if !defined(__UCLIBC__)
> >>> #include <gnu/libc-version.h>
> >>> #else
> >>> #define XSTR(s) STR(s)
> >>> #define STR(s) #s
> >>> #endif
> >>>
> >>> int main(void)
> >>> {
> >>> #if !defined(__UCLIBC__)
> >>> 	const char *version = gnu_get_libc_version();
> >>> #else
> >>> 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> >>> #endif
> >>>
> >>> 	return (long)version;
> >>> }
> >>> [acme@quaco linux]$
> >>>
> >>> [perfbuilder@59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
> >>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
> >>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
> >>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
> >>> [perfbuilder@59ca4b424ded /]$
> >>>
> >>> Isn't that part of uClibc?
> >>
> >> Right you are. Per the big fat comment right above that code, this gross hack in
> >> uclibc is unavoidable as applications tend to rely on that define.
> >> So a better fix would be to check for various !GLIBC libs explicitly.
> >>
> >> #ifdef __UCLIBC__
> >>
> >> #elseif defined __MUSL__
> >>
> >> ....
> >>
> >> Not pretty from app usage pov, but that seems to be the only sane way of doing it.
> > 
> > What are you trying to achieve? I was just CC'd and I'm missing the
> > context.
> 
> Sorry I added you as a subject matter expert but didn't provide enough context.
> 
> The original issue [1] was perf failing to build on ARC due to perf tools needing
> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
> 
> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html

I think you misunderstood -- I'm asking what you're trying to achieve
by detecting whether the libc is glibc, rather than whether it has
some particular interface you want to conditionally use. This is a
major smell and is usually something wrong that shouldn't be done.

Rich

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
@ 2019-05-01  3:12                 ` Rich Felker
  0 siblings, 0 replies; 55+ messages in thread
From: Rich Felker @ 2019-05-01  3:12 UTC (permalink / raw)
  To: linux-snps-arc

On Tue, Apr 30, 2019@10:13:40AM -0700, Vineet Gupta wrote:
> On 4/30/19 10:04 AM, Rich Felker wrote:
> > On Tue, Apr 30, 2019@03:53:18PM +0000, Vineet Gupta wrote:
> >> On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
> >>>>> Auto-detecting system features:
> >>>>> ...                         dwarf: [ OFF ]
> >>>>> ...            dwarf_getlocations: [ OFF ]
> >>>>> ...                         glibc: [ on  ]
> >>>> Not related to current issue, this run uses a uClibc toolchain and yet it is
> >>>> detecting glibc - doesn't seem right to me.
> >>> Ok, I'll improve that, I think it just tries to detect a libc, yeah,
> >>> see:
> >>>
> >>> [acme at quaco linux]$ cat tools/build/feature/test-glibc.c
> >>> // SPDX-License-Identifier: GPL-2.0
> >>> #include <stdlib.h>
> >>>
> >>> #if !defined(__UCLIBC__)
> >>> #include <gnu/libc-version.h>
> >>> #else
> >>> #define XSTR(s) STR(s)
> >>> #define STR(s) #s
> >>> #endif
> >>>
> >>> int main(void)
> >>> {
> >>> #if !defined(__UCLIBC__)
> >>> 	const char *version = gnu_get_libc_version();
> >>> #else
> >>> 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> >>> #endif
> >>>
> >>> 	return (long)version;
> >>> }
> >>> [acme at quaco linux]$
> >>>
> >>> [perfbuilder at 59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
> >>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
> >>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
> >>> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
> >>> [perfbuilder at 59ca4b424ded /]$
> >>>
> >>> Isn't that part of uClibc?
> >>
> >> Right you are. Per the big fat comment right above that code, this gross hack in
> >> uclibc is unavoidable as applications tend to rely on that define.
> >> So a better fix would be to check for various !GLIBC libs explicitly.
> >>
> >> #ifdef __UCLIBC__
> >>
> >> #elseif defined __MUSL__
> >>
> >> ....
> >>
> >> Not pretty from app usage pov, but that seems to be the only sane way of doing it.
> > 
> > What are you trying to achieve? I was just CC'd and I'm missing the
> > context.
> 
> Sorry I added you as a subject matter expert but didn't provide enough context.
> 
> The original issue [1] was perf failing to build on ARC due to perf tools needing
> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
> 
> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html

I think you misunderstood -- I'm asking what you're trying to achieve
by detecting whether the libc is glibc, rather than whether it has
some particular interface you want to conditionally use. This is a
major smell and is usually something wrong that shouldn't be done.

Rich

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-30 16:12       ` Arnd Bergmann
@ 2019-05-01 20:41         ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-01 20:41 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Vineet Gupta, Arnaldo Carvalho de Melo, lkml, linux-perf-users,
	Jiri Olsa, Namhyung Kim, arcml

Em Tue, Apr 30, 2019 at 06:12:35PM +0200, Arnd Bergmann escreveu:
> On Mon, Apr 29, 2019 at 7:17 PM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
> >
> > On 4/22/19 8:31 AM, Arnaldo Carvalho de Melo wrote:
> > >> A quick fix for ARC will be to create our own version but I presume all existing
> > >> arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
> > >> send out a patch for ARC.
> > >>
> > >> P.S. Why do we need the unistd.h duplication in tools directory, given it could
> > >> have used the in-tree unistd headers directly ?
> > > I have to write down the explanation and have it in a file, but we can't
> > > use anything in the kernel from outside tools/ to avoid adding a burden
> > > to kernel developers that would then have to make sure that the changes
> > > that they make outside tools/ don't break things living there.
> >
> > That is a sound guiding principle in general but I don't agree here. unistd is
> > backbone of kernel user interface it has to work and can't possibly be broken even
> > when kernel devs add a new syscall is added or condition-alize existing one. So
> > adding a copy - and deferring the propagation of in-kernel unistd to usersapce
> > won't necessarily help with anything and it just adds the burden of keeping them
> > in sync. Granted we won't necessarily need all the bleeding edge (new syscall
> > updates) into that header, its still more work.
> 
> I think more importantly, it seems completely broken to sync a file from
> asm-generic but not the arch specific file that includes it.
> 
> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
> missed all the other architectures changed in c8ce48f06503 and the
> related commits.

Right, I have a patch copying the missing headers, and that fixed the
build with the glibc-based toolchain, but then broke the uCLibc one :-\

I'm travelling, so coulnd't get back to this, will try as possible.

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-05-01 20:41         ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-01 20:41 UTC (permalink / raw)
  To: linux-snps-arc

Em Tue, Apr 30, 2019 at 06:12:35PM +0200, Arnd Bergmann escreveu:
> On Mon, Apr 29, 2019@7:17 PM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
> >
> > On 4/22/19 8:31 AM, Arnaldo Carvalho de Melo wrote:
> > >> A quick fix for ARC will be to create our own version but I presume all existing
> > >> arches using generic syscall abi are affected. Thoughts ? In lack of ideas I'll
> > >> send out a patch for ARC.
> > >>
> > >> P.S. Why do we need the unistd.h duplication in tools directory, given it could
> > >> have used the in-tree unistd headers directly ?
> > > I have to write down the explanation and have it in a file, but we can't
> > > use anything in the kernel from outside tools/ to avoid adding a burden
> > > to kernel developers that would then have to make sure that the changes
> > > that they make outside tools/ don't break things living there.
> >
> > That is a sound guiding principle in general but I don't agree here. unistd is
> > backbone of kernel user interface it has to work and can't possibly be broken even
> > when kernel devs add a new syscall is added or condition-alize existing one. So
> > adding a copy - and deferring the propagation of in-kernel unistd to usersapce
> > won't necessarily help with anything and it just adds the burden of keeping them
> > in sync. Granted we won't necessarily need all the bleeding edge (new syscall
> > updates) into that header, its still more work.
> 
> I think more importantly, it seems completely broken to sync a file from
> asm-generic but not the arch specific file that includes it.
> 
> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
> missed all the other architectures changed in c8ce48f06503 and the
> related commits.

Right, I have a patch copying the missing headers, and that fixed the
build with the glibc-based toolchain, but then broke the uCLibc one :-\

I'm travelling, so coulnd't get back to this, will try as possible.

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-05-01 20:41         ` Arnaldo Carvalho de Melo
@ 2019-05-01 21:17           ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-01 21:17 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, Arnd Bergmann
  Cc: Rich Felker, Arnaldo Carvalho de Melo, lkml, linux-perf-users,
	Jiri Olsa, Namhyung Kim, arcml

On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
>> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
>> missed all the other architectures changed in c8ce48f06503 and the
>> related commits.
> Right, I have a patch copying the missing headers, and that fixed the
> build with the glibc-based toolchain, but then broke the uCLibc one :-\

tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
asm/unistd.h

uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
(generated by parsing kernel's unistd). This header does the right thing by
chekcing for redefs, but in the end we still collide with newly added
tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
this is not an ARC problem, any uClibc build would be affected. Do you have a arm
uclibc toolchain to test ?

All in all this is a mess. The quick band aid I can think of would be to add a
#ifndef __UCLIBC__ in tools/arch/arc/include/uapi/asm/unistd.h which is super
ugly, but in the end the solution is to get rid of this header duplicity.

-Vineet

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-05-01 21:17           ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-01 21:17 UTC (permalink / raw)
  To: linux-snps-arc

On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
>> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
>> missed all the other architectures changed in c8ce48f06503 and the
>> related commits.
> Right, I have a patch copying the missing headers, and that fixed the
> build with the glibc-based toolchain, but then broke the uCLibc one :-\

tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
asm/unistd.h

uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
(generated by parsing kernel's unistd). This header does the right thing by
chekcing for redefs, but in the end we still collide with newly added
tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
this is not an ARC problem, any uClibc build would be affected. Do you have a arm
uclibc toolchain to test ?

All in all this is a mess. The quick band aid I can think of would be to add a
#ifndef __UCLIBC__ in tools/arch/arc/include/uapi/asm/unistd.h which is super
ugly, but in the end the solution is to get rid of this header duplicity.

-Vineet

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-05-01 21:17           ` Vineet Gupta
  (?)
@ 2019-05-02 14:36             ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 14:36 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnaldo Carvalho de Melo, Arnd Bergmann, Rich Felker,
	Arnaldo Carvalho de Melo, lkml, linux-perf-users, Jiri Olsa,
	Namhyung Kim, arcml

Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
> On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
> >> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
> >> missed all the other architectures changed in c8ce48f06503 and the
> >> related commits.
> > Right, I have a patch copying the missing headers, and that fixed the
> > build with the glibc-based toolchain, but then broke the uCLibc one :-\
 
> tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
> asm/unistd.h
 
> uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
> (generated by parsing kernel's unistd). This header does the right thing by
> chekcing for redefs, but in the end we still collide with newly added
> tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
> this is not an ARC problem, any uClibc build would be affected. Do you have a arm
> uclibc toolchain to test ?

This solves it for fedora:29,
arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.

Also ok with:

  make -C tools/perf build-test

Now build testing with the full set of containers.

- Arnaldo

commit 1931594a680dba28e98b526192dd065430c850c0
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu May 2 09:26:23 2019 -0400

    perf tools: Remove needless asm/unistd.h include fixing build in some places
    
    We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h
    includes asm/unistd.h, sometimes this leads to the redefinition of
    defines, breaking the build.
    
    Noticed on ARC with uCLibc.
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Rich Felker <dalias@libc.org>
    Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
    Link: https://lkml.kernel.org/n/tip-xjpf80o64i2ko74aj2jih0qg@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
index ca0fff6272be..06f48312c5ed 100644
--- a/tools/perf/util/cloexec.c
+++ b/tools/perf/util/cloexec.c
@@ -7,7 +7,6 @@
 #include "asm/bug.h"
 #include "debug.h"
 #include <unistd.h>
-#include <asm/unistd.h>
 #include <sys/syscall.h>
 
 static unsigned long flag = PERF_FLAG_FD_CLOEXEC;

^ permalink raw reply related	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
@ 2019-05-02 14:36             ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 14:36 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: linux-perf-users, Rich Felker, Arnd Bergmann,
	Arnaldo Carvalho de Melo, lkml, Arnaldo Carvalho de Melo,
	Jiri Olsa, Namhyung Kim, arcml

Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
> On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
> >> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
> >> missed all the other architectures changed in c8ce48f06503 and the
> >> related commits.
> > Right, I have a patch copying the missing headers, and that fixed the
> > build with the glibc-based toolchain, but then broke the uCLibc one :-\
 
> tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
> asm/unistd.h
 
> uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
> (generated by parsing kernel's unistd). This header does the right thing by
> chekcing for redefs, but in the end we still collide with newly added
> tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
> this is not an ARC problem, any uClibc build would be affected. Do you have a arm
> uclibc toolchain to test ?

This solves it for fedora:29,
arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.

Also ok with:

  make -C tools/perf build-test

Now build testing with the full set of containers.

- Arnaldo

commit 1931594a680dba28e98b526192dd065430c850c0
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu May 2 09:26:23 2019 -0400

    perf tools: Remove needless asm/unistd.h include fixing build in some places
    
    We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h
    includes asm/unistd.h, sometimes this leads to the redefinition of
    defines, breaking the build.
    
    Noticed on ARC with uCLibc.
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Rich Felker <dalias@libc.org>
    Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
    Link: https://lkml.kernel.org/n/tip-xjpf80o64i2ko74aj2jih0qg@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
index ca0fff6272be..06f48312c5ed 100644
--- a/tools/perf/util/cloexec.c
+++ b/tools/perf/util/cloexec.c
@@ -7,7 +7,6 @@
 #include "asm/bug.h"
 #include "debug.h"
 #include <unistd.h>
-#include <asm/unistd.h>
 #include <sys/syscall.h>
 
 static unsigned long flag = PERF_FLAG_FD_CLOEXEC;

^ permalink raw reply related	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-05-02 14:36             ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 14:36 UTC (permalink / raw)
  To: linux-snps-arc

Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
> On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
> >> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
> >> missed all the other architectures changed in c8ce48f06503 and the
> >> related commits.
> > Right, I have a patch copying the missing headers, and that fixed the
> > build with the glibc-based toolchain, but then broke the uCLibc one :-\
 
> tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
> asm/unistd.h
 
> uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
> (generated by parsing kernel's unistd). This header does the right thing by
> chekcing for redefs, but in the end we still collide with newly added
> tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
> this is not an ARC problem, any uClibc build would be affected. Do you have a arm
> uclibc toolchain to test ?

This solves it for fedora:29,
arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.

Also ok with:

  make -C tools/perf build-test

Now build testing with the full set of containers.

- Arnaldo

commit 1931594a680dba28e98b526192dd065430c850c0
Author: Arnaldo Carvalho de Melo <acme at redhat.com>
Date:   Thu May 2 09:26:23 2019 -0400

    perf tools: Remove needless asm/unistd.h include fixing build in some places
    
    We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h
    includes asm/unistd.h, sometimes this leads to the redefinition of
    defines, breaking the build.
    
    Noticed on ARC with uCLibc.
    
    Cc: Adrian Hunter <adrian.hunter at intel.com>
    Cc: Arnaldo Carvalho de Melo <arnaldo.melo at gmail.com>
    Cc: Arnd Bergmann <arnd at arndb.de>
    Cc: Jiri Olsa <jolsa at kernel.org>
    Cc: Namhyung Kim <namhyung at kernel.org>
    Cc: Rich Felker <dalias at libc.org>
    Cc: Vineet Gupta <Vineet.Gupta1 at synopsys.com>
    Link: https://lkml.kernel.org/n/tip-xjpf80o64i2ko74aj2jih0qg at git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme at redhat.com>

diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
index ca0fff6272be..06f48312c5ed 100644
--- a/tools/perf/util/cloexec.c
+++ b/tools/perf/util/cloexec.c
@@ -7,7 +7,6 @@
 #include "asm/bug.h"
 #include "debug.h"
 #include <unistd.h>
-#include <asm/unistd.h>
 #include <sys/syscall.h>
 
 static unsigned long flag = PERF_FLAG_FD_CLOEXEC;

^ permalink raw reply related	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-05-02 14:36             ` Arnaldo Carvalho de Melo
@ 2019-05-02 15:41               ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 15:41 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnd Bergmann, Rich Felker, Arnaldo Carvalho de Melo, lkml,
	linux-perf-users, Jiri Olsa, Namhyung Kim, arcml

Em Thu, May 02, 2019 at 10:36:18AM -0400, Arnaldo Carvalho de Melo escreveu:
> Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
> > On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
> > >> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
> > >> missed all the other architectures changed in c8ce48f06503 and the
> > >> related commits.
> > > Right, I have a patch copying the missing headers, and that fixed the
> > > build with the glibc-based toolchain, but then broke the uCLibc one :-\
>  
> > tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
> > asm/unistd.h
>  
> > uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
> > (generated by parsing kernel's unistd). This header does the right thing by
> > chekcing for redefs, but in the end we still collide with newly added
> > tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
> > this is not an ARC problem, any uClibc build would be affected. Do you have a arm
> > uclibc toolchain to test ?
> 
> This solves it for fedora:29,
> arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
> arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
> arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.
> 
> Also ok with:
> 
>   make -C tools/perf build-test
> 
> Now build testing with the full set of containers.

So far, and the alpine ones use musl libc:

[perfbuilder@quaco ~]$ export PERF_TARBALL=http://192.168.124.1/perf/perf-5.1.0-rc6.tar.xz
[perfbuilder@quaco ~]$ time dm
   1 alpine:3.4                    : Ok   gcc (Alpine 5.3.0) 5.3.0
   2 alpine:3.5                    : Ok   gcc (Alpine 6.2.1) 6.2.1 20160822
   3 alpine:3.6                    : Ok   gcc (Alpine 6.3.0) 6.3.0
   4 alpine:3.7                    : Ok   gcc (Alpine 6.4.0) 6.4.0
   5 alpine:3.8                    : Ok   gcc (Alpine 6.4.0) 6.4.0
   6 alpine:3.9                    : Ok   gcc (Alpine 8.3.0) 8.3.0
   7 alpine:edge                   : Ok   gcc (Alpine 8.3.0) 8.3.0
   8 amazonlinux:1                 : Ok   gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
   9 android-ndk:r12b-arm          : Ok   arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
  10 android-ndk:r15c-arm          : Ok   arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
  11 centos:5                      : Ok   gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
  12 centos:6                      : Ok   gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
  13 centos:7                      : Ok   gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
  14 debian:8                      : Ok   gcc (Debian 4.9.2-10+deb8u2) 4.9.2
  15 debian:9                      : Ok   gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
  16 debian:experimental           : Ok   gcc (Debian 8.3.0-6) 8.3.0
  17 debian:experimental-x-arm64   : Ok   aarch64-linux-gnu-gcc (Debian 8.3.0-4) 8.3.0
  18 debian:experimental-x-mips    : Ok   mips-linux-gnu-gcc (Debian 8.3.0-4) 8.3.0
  19 debian:experimental-x-mips64  : Ok   mips64-linux-gnuabi64-gcc (Debian 8.3.0-2) 8.3.0
  20 debian:experimental-x-mipsel  : Ok   mipsel-linux-gnu-gcc (Debian 8.3.0-4) 8.3.0
  21 fedora:20                     : Ok   gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
  22 fedora:22                     : Ok   gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
  23 fedora:23                     : Ok   gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
  24 fedora:24                     : Ok   gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
  25 fedora:24-x-ARC-uClibc        : Ok   arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710


- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-05-02 15:41               ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 15:41 UTC (permalink / raw)
  To: linux-snps-arc

Em Thu, May 02, 2019 at 10:36:18AM -0400, Arnaldo Carvalho de Melo escreveu:
> Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
> > On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
> > >> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
> > >> missed all the other architectures changed in c8ce48f06503 and the
> > >> related commits.
> > > Right, I have a patch copying the missing headers, and that fixed the
> > > build with the glibc-based toolchain, but then broke the uCLibc one :-\
>  
> > tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
> > asm/unistd.h
>  
> > uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
> > (generated by parsing kernel's unistd). This header does the right thing by
> > chekcing for redefs, but in the end we still collide with newly added
> > tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
> > this is not an ARC problem, any uClibc build would be affected. Do you have a arm
> > uclibc toolchain to test ?
> 
> This solves it for fedora:29,
> arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
> arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
> arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.
> 
> Also ok with:
> 
>   make -C tools/perf build-test
> 
> Now build testing with the full set of containers.

So far, and the alpine ones use musl libc:

[perfbuilder at quaco ~]$ export PERF_TARBALL=http://192.168.124.1/perf/perf-5.1.0-rc6.tar.xz
[perfbuilder at quaco ~]$ time dm
   1 alpine:3.4                    : Ok   gcc (Alpine 5.3.0) 5.3.0
   2 alpine:3.5                    : Ok   gcc (Alpine 6.2.1) 6.2.1 20160822
   3 alpine:3.6                    : Ok   gcc (Alpine 6.3.0) 6.3.0
   4 alpine:3.7                    : Ok   gcc (Alpine 6.4.0) 6.4.0
   5 alpine:3.8                    : Ok   gcc (Alpine 6.4.0) 6.4.0
   6 alpine:3.9                    : Ok   gcc (Alpine 8.3.0) 8.3.0
   7 alpine:edge                   : Ok   gcc (Alpine 8.3.0) 8.3.0
   8 amazonlinux:1                 : Ok   gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
   9 android-ndk:r12b-arm          : Ok   arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
  10 android-ndk:r15c-arm          : Ok   arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
  11 centos:5                      : Ok   gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
  12 centos:6                      : Ok   gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
  13 centos:7                      : Ok   gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
  14 debian:8                      : Ok   gcc (Debian 4.9.2-10+deb8u2) 4.9.2
  15 debian:9                      : Ok   gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
  16 debian:experimental           : Ok   gcc (Debian 8.3.0-6) 8.3.0
  17 debian:experimental-x-arm64   : Ok   aarch64-linux-gnu-gcc (Debian 8.3.0-4) 8.3.0
  18 debian:experimental-x-mips    : Ok   mips-linux-gnu-gcc (Debian 8.3.0-4) 8.3.0
  19 debian:experimental-x-mips64  : Ok   mips64-linux-gnuabi64-gcc (Debian 8.3.0-2) 8.3.0
  20 debian:experimental-x-mipsel  : Ok   mipsel-linux-gnu-gcc (Debian 8.3.0-4) 8.3.0
  21 fedora:20                     : Ok   gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
  22 fedora:22                     : Ok   gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
  23 fedora:23                     : Ok   gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
  24 fedora:24                     : Ok   gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
  25 fedora:24-x-ARC-uClibc        : Ok   arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710


- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-05-02 14:36             ` Arnaldo Carvalho de Melo
  (?)
@ 2019-05-02 16:09               ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 16:09 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Arnd Bergmann, Rich Felker, Arnaldo Carvalho de Melo, lkml,
	linux-perf-users, Jiri Olsa, Namhyung Kim, arcml

On 5/2/19 7:36 AM, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
>> On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
>>>> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
>>>> missed all the other architectures changed in c8ce48f06503 and the
>>>> related commits.
>>> Right, I have a patch copying the missing headers, and that fixed the
>>> build with the glibc-based toolchain, but then broke the uCLibc one :-\
>  
>> tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
>> asm/unistd.h
>  
>> uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
>> (generated by parsing kernel's unistd). This header does the right thing by
>> chekcing for redefs, but in the end we still collide with newly added
>> tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
>> this is not an ARC problem, any uClibc build would be affected. Do you have a arm
>> uclibc toolchain to test ?
> This solves it for fedora:29,
> arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
> arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
> arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.
>
> Also ok with:
>
>   make -C tools/perf build-test
>
> Now build testing with the full set of containers.
>
> - Arnaldo
>
> commit 1931594a680dba28e98b526192dd065430c850c0
> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date:   Thu May 2 09:26:23 2019 -0400
>
>     perf tools: Remove needless asm/unistd.h include fixing build in some places
>     
>     We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h
>     includes asm/unistd.h, sometimes this leads to the redefinition of
>     defines, breaking the build.
>     
>     Noticed on ARC with uCLibc.

Thx for this Arnaldo.

While this takes care of immediate issues, for the long term, are you open to idea
of removing the header duplicity.
We could use a "less evil" idiom of copying only the minimal bits (since the sync
onus remains one way or the other)
e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects

#ifdef __NR_xx
# if defined (__arch_y__)

# elif defined (__arch_z__)

# endif
#endif



^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
@ 2019-05-02 16:09               ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 16:09 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: linux-perf-users, Rich Felker, Arnd Bergmann, lkml,
	Arnaldo Carvalho de Melo, Jiri Olsa, Namhyung Kim, arcml

On 5/2/19 7:36 AM, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
>> On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
>>>> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
>>>> missed all the other architectures changed in c8ce48f06503 and the
>>>> related commits.
>>> Right, I have a patch copying the missing headers, and that fixed the
>>> build with the glibc-based toolchain, but then broke the uCLibc one :-\
>  
>> tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
>> asm/unistd.h
>  
>> uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
>> (generated by parsing kernel's unistd). This header does the right thing by
>> chekcing for redefs, but in the end we still collide with newly added
>> tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
>> this is not an ARC problem, any uClibc build would be affected. Do you have a arm
>> uclibc toolchain to test ?
> This solves it for fedora:29,
> arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
> arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
> arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.
>
> Also ok with:
>
>   make -C tools/perf build-test
>
> Now build testing with the full set of containers.
>
> - Arnaldo
>
> commit 1931594a680dba28e98b526192dd065430c850c0
> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date:   Thu May 2 09:26:23 2019 -0400
>
>     perf tools: Remove needless asm/unistd.h include fixing build in some places
>     
>     We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h
>     includes asm/unistd.h, sometimes this leads to the redefinition of
>     defines, breaking the build.
>     
>     Noticed on ARC with uCLibc.

Thx for this Arnaldo.

While this takes care of immediate issues, for the long term, are you open to idea
of removing the header duplicity.
We could use a "less evil" idiom of copying only the minimal bits (since the sync
onus remains one way or the other)
e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects

#ifdef __NR_xx
# if defined (__arch_y__)

# elif defined (__arch_z__)

# endif
#endif

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-05-02 16:09               ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 16:09 UTC (permalink / raw)
  To: linux-snps-arc

On 5/2/19 7:36 AM, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
>> On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
>>>> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
>>>> missed all the other architectures changed in c8ce48f06503 and the
>>>> related commits.
>>> Right, I have a patch copying the missing headers, and that fixed the
>>> build with the glibc-based toolchain, but then broke the uCLibc one :-\
>  
>> tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
>> asm/unistd.h
>  
>> uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
>> (generated by parsing kernel's unistd). This header does the right thing by
>> chekcing for redefs, but in the end we still collide with newly added
>> tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
>> this is not an ARC problem, any uClibc build would be affected. Do you have a arm
>> uclibc toolchain to test ?
> This solves it for fedora:29,
> arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
> arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
> arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.
>
> Also ok with:
>
>   make -C tools/perf build-test
>
> Now build testing with the full set of containers.
>
> - Arnaldo
>
> commit 1931594a680dba28e98b526192dd065430c850c0
> Author: Arnaldo Carvalho de Melo <acme at redhat.com>
> Date:   Thu May 2 09:26:23 2019 -0400
>
>     perf tools: Remove needless asm/unistd.h include fixing build in some places
>     
>     We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h
>     includes asm/unistd.h, sometimes this leads to the redefinition of
>     defines, breaking the build.
>     
>     Noticed on ARC with uCLibc.

Thx for this Arnaldo.

While this takes care of immediate issues, for the long term, are you open to idea
of removing the header duplicity.
We could use a "less evil" idiom of copying only the minimal bits (since the sync
onus remains one way or the other)
e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects

#ifdef __NR_xx
# if defined (__arch_y__)

# elif defined (__arch_z__)

# endif
#endif

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-05-02 16:09               ` Vineet Gupta
@ 2019-05-02 16:41                 ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 16:41 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Arnaldo Carvalho de Melo, Arnd Bergmann, Rich Felker,
	Arnaldo Carvalho de Melo, lkml, linux-perf-users, Jiri Olsa,
	Namhyung Kim, arcml

Em Thu, May 02, 2019 at 04:09:43PM +0000, Vineet Gupta escreveu:
> On 5/2/19 7:36 AM, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
> >> On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
> >>>> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
> >>>> missed all the other architectures changed in c8ce48f06503 and the
> >>>> related commits.
> >>> Right, I have a patch copying the missing headers, and that fixed the
> >>> build with the glibc-based toolchain, but then broke the uCLibc one :-\
> >  
> >> tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
> >> asm/unistd.h
> >  
> >> uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
> >> (generated by parsing kernel's unistd). This header does the right thing by
> >> chekcing for redefs, but in the end we still collide with newly added
> >> tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
> >> this is not an ARC problem, any uClibc build would be affected. Do you have a arm
> >> uclibc toolchain to test ?
> > This solves it for fedora:29,
> > arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
> > arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
> > arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.
> >
> > Also ok with:
> >
> >   make -C tools/perf build-test
> >
> > Now build testing with the full set of containers.
> >
> > - Arnaldo
> >
> > commit 1931594a680dba28e98b526192dd065430c850c0
> > Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> > Date:   Thu May 2 09:26:23 2019 -0400
> >
> >     perf tools: Remove needless asm/unistd.h include fixing build in some places
> >     
> >     We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h
> >     includes asm/unistd.h, sometimes this leads to the redefinition of
> >     defines, breaking the build.
> >     
> >     Noticed on ARC with uCLibc.
> 
> Thx for this Arnaldo.
> 
> While this takes care of immediate issues, for the long term, are you open to idea
> of removing the header duplicity.

In the beginning we used the kernel headers directly, then, acting on
advice/complaints from Linus about tooling breaking when changes were
made in the kernel sources we were using directly, we moved to have
copies and notice when things change so that we could think about what
changed and act accordingly, without putting the burden to the kernel
developers to keep tools/ building, I want to keep it that way.

Now you say, validly, that there are bits that are designed to be used
by userspace, so for those, we should go back to not copying and using
it direcly, elliminating the duplicity you don't like.

I don't know, I'm used to the duplicity and the checks, not breaking
tools even when kernel developers make mistakes in the UAPI headers,
tools/perf is self container wrt the latest and greatest stuff not
present in older environments, and the onus is on perf developers to do
the sync.

This specific issue here happened because I made a mistake, which I
fixed when reported, now I have three containers for cross building for
ARC, two versions for the uCLibc based toolchain, one for the glibc one,
libnuma, elfutils and zlib are cross build there, so should make it less
likely problems like this will happen again.

> We could use a "less evil" idiom of copying only the minimal bits (since the sync
> onus remains one way or the other)
> e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects
 
> #ifdef __NR_xx
> # if defined (__arch_y__)
> 
> # elif defined (__arch_z__)
> 
> # endif
> #endif

- Arnaldo

BTW: since the last report:

  25 fedora:24-x-ARC-uClibc        : Ok   arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
  26 fedora:25                     : Ok   gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
  27 fedora:26                     : Ok   gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)
  28 fedora:28                     : Ok   gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
  29 fedora:29                     : Ok   gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
  30 fedora:30                     : Ok   gcc (GCC) 9.0.1 20190312 (Red Hat 9.0.1-0.10)
  31 fedora:30-x-ARC-glibc         : Ok   arc-linux-gcc (ARC HS GNU/Linux glibc toolchain 2019.03-rc1) 8.3.1 20190225
  32 fedora:30-x-ARC-uClibc        : Ok   arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-05-02 16:41                 ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 16:41 UTC (permalink / raw)
  To: linux-snps-arc

Em Thu, May 02, 2019 at 04:09:43PM +0000, Vineet Gupta escreveu:
> On 5/2/19 7:36 AM, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 01, 2019 at 09:17:52PM +0000, Vineet Gupta escreveu:
> >> On 5/1/19 1:41 PM, Arnaldo Carvalho de Melo wrote:
> >>>> The 1a787fc5ba18ac7 commit copied over the changes for arm64, but
> >>>> missed all the other architectures changed in c8ce48f06503 and the
> >>>> related commits.
> >>> Right, I have a patch copying the missing headers, and that fixed the
> >>> build with the glibc-based toolchain, but then broke the uCLibc one :-\
> >  
> >> tools/perf/util/cloexec.c  #includes <sys/syscall.h> which for glibc includes
> >> asm/unistd.h
> >  
> >> uClibc <sys/syscall.h> OTOH #include <bits/sysnum.h> containign#define __NR_*
> >> (generated by parsing kernel's unistd). This header does the right thing by
> >> chekcing for redefs, but in the end we still collide with newly added
> >> tools/arc/arc/*/**/unistd.h which doesn't have conditional definitions. I'm sure
> >> this is not an ARC problem, any uClibc build would be affected. Do you have a arm
> >> uclibc toolchain to test ?
> > This solves it for fedora:29,
> > arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install,
> > arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install and
> > arc_gnu_2019.03-rc1_prebuilt_glibc_le_archs_linux_install.
> >
> > Also ok with:
> >
> >   make -C tools/perf build-test
> >
> > Now build testing with the full set of containers.
> >
> > - Arnaldo
> >
> > commit 1931594a680dba28e98b526192dd065430c850c0
> > Author: Arnaldo Carvalho de Melo <acme at redhat.com>
> > Date:   Thu May 2 09:26:23 2019 -0400
> >
> >     perf tools: Remove needless asm/unistd.h include fixing build in some places
> >     
> >     We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h
> >     includes asm/unistd.h, sometimes this leads to the redefinition of
> >     defines, breaking the build.
> >     
> >     Noticed on ARC with uCLibc.
> 
> Thx for this Arnaldo.
> 
> While this takes care of immediate issues, for the long term, are you open to idea
> of removing the header duplicity.

In the beginning we used the kernel headers directly, then, acting on
advice/complaints from Linus about tooling breaking when changes were
made in the kernel sources we were using directly, we moved to have
copies and notice when things change so that we could think about what
changed and act accordingly, without putting the burden to the kernel
developers to keep tools/ building, I want to keep it that way.

Now you say, validly, that there are bits that are designed to be used
by userspace, so for those, we should go back to not copying and using
it direcly, elliminating the duplicity you don't like.

I don't know, I'm used to the duplicity and the checks, not breaking
tools even when kernel developers make mistakes in the UAPI headers,
tools/perf is self container wrt the latest and greatest stuff not
present in older environments, and the onus is on perf developers to do
the sync.

This specific issue here happened because I made a mistake, which I
fixed when reported, now I have three containers for cross building for
ARC, two versions for the uCLibc based toolchain, one for the glibc one,
libnuma, elfutils and zlib are cross build there, so should make it less
likely problems like this will happen again.

> We could use a "less evil" idiom of copying only the minimal bits (since the sync
> onus remains one way or the other)
> e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects
 
> #ifdef __NR_xx
> # if defined (__arch_y__)
> 
> # elif defined (__arch_z__)
> 
> # endif
> #endif

- Arnaldo

BTW: since the last report:

  25 fedora:24-x-ARC-uClibc        : Ok   arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
  26 fedora:25                     : Ok   gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
  27 fedora:26                     : Ok   gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)
  28 fedora:28                     : Ok   gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
  29 fedora:29                     : Ok   gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
  30 fedora:30                     : Ok   gcc (GCC) 9.0.1 20190312 (Red Hat 9.0.1-0.10)
  31 fedora:30-x-ARC-glibc         : Ok   arc-linux-gcc (ARC HS GNU/Linux glibc toolchain 2019.03-rc1) 8.3.1 20190225
  32 fedora:30-x-ARC-uClibc        : Ok   arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-04-30  1:18         ` Arnaldo Carvalho de Melo
@ 2019-05-02 16:53           ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 16:53 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Arnaldo Carvalho de Melo, Arnd Bergmann,
	Arnaldo Carvalho de Melo, lkml, linux-perf-users, Jiri Olsa,
	Namhyung Kim, arcml

On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
>>>
>>> Auto-detecting system features:
>>> ...                         dwarf: [ OFF ]
>>> ...            dwarf_getlocations: [ OFF ]
>>> ...                         glibc: [ on  ]
>>
>> Not related to current issue, this run uses a uClibc toolchain and yet it is
>> detecting glibc - doesn't seem right to me.
> 
> Ok, I'll improve that, I think it just tries to detect a libc, yeah,
> see:
> 
> [acme@quaco linux]$ cat tools/build/feature/test-glibc.c
> // SPDX-License-Identifier: GPL-2.0
> #include <stdlib.h>
> 
> #if !defined(__UCLIBC__)
> #include <gnu/libc-version.h>
> #else
> #define XSTR(s) STR(s)
> #define STR(s) #s
> #endif
> 
> int main(void)
> {
> #if !defined(__UCLIBC__)
> 	const char *version = gnu_get_libc_version();
> #else
> 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> #endif
> 
> 	return (long)version;
> }

So we return a pointer to a string to declare a glibc build ?
But won't it do so even for other libs, even if those numbers were 0:0. I'm
confused how this feature detction works.

> [acme@quaco linux]$
> 
> [perfbuilder@59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
> [perfbuilder@59ca4b424ded /]$
> 
> Isn't that part of uClibc?

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-05-02 16:53           ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 16:53 UTC (permalink / raw)
  To: linux-snps-arc

On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
>>>
>>> Auto-detecting system features:
>>> ...                         dwarf: [ OFF ]
>>> ...            dwarf_getlocations: [ OFF ]
>>> ...                         glibc: [ on  ]
>>
>> Not related to current issue, this run uses a uClibc toolchain and yet it is
>> detecting glibc - doesn't seem right to me.
> 
> Ok, I'll improve that, I think it just tries to detect a libc, yeah,
> see:
> 
> [acme at quaco linux]$ cat tools/build/feature/test-glibc.c
> // SPDX-License-Identifier: GPL-2.0
> #include <stdlib.h>
> 
> #if !defined(__UCLIBC__)
> #include <gnu/libc-version.h>
> #else
> #define XSTR(s) STR(s)
> #define STR(s) #s
> #endif
> 
> int main(void)
> {
> #if !defined(__UCLIBC__)
> 	const char *version = gnu_get_libc_version();
> #else
> 	const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
> #endif
> 
> 	return (long)version;
> }

So we return a pointer to a string to declare a glibc build ?
But won't it do so even for other libs, even if those numbers were 0:0. I'm
confused how this feature detction works.

> [acme at quaco linux]$
> 
> [perfbuilder at 59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:   The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define	__GLIBC__	2
> /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:	((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
> [perfbuilder at 59ca4b424ded /]$
> 
> Isn't that part of uClibc?

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
  2019-05-01  3:12                 ` Rich Felker
  (?)
@ 2019-05-02 16:55                   ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 16:55 UTC (permalink / raw)
  To: Rich Felker, Jin Yao
  Cc: Arnaldo Carvalho de Melo, devel, linux-perf-users,
	Arnaldo Carvalho de Melo, lkml, arcml, Arnd Bergmann, Jiri Olsa,
	Namhyung Kim

On 4/30/19 8:12 PM, Rich Felker wrote:
>>> What are you trying to achieve? I was just CC'd and I'm missing the
>>> context.
>>
>> Sorry I added you as a subject matter expert but didn't provide enough context.
>>
>> The original issue [1] was perf failing to build on ARC due to perf tools needing
>> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
>> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
>> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
>> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
>>
>> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
>> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html
> 
> I think you misunderstood -- 

:-)

> I'm asking what you're trying to achieve
> by detecting whether the libc is glibc, rather than whether it has
> some particular interface you want to conditionally use. This is a
> major smell and is usually something wrong that shouldn't be done.

Good question indeed. Back in 2015 I initially ran into some quirks due to subtle
libc differences.  At the time perf has a fwd ref for strlcpy which exactly
matched glibc but not uClibc.  see commit  a83d869f300bf91 "(perf tools: Elide
strlcpy warning with uclibc)" or 0215d59b154 "(tools lib: Reinstate strlcpy()
header guard with __UCLIBC__)"

But this still used the libc defined symbol __UCLIBC__ or __GLIBC__

Your question however pertains to perf glibc feature check where perf generates an
alternate symbol HAVE_GLIBC_SUPPORT.

This is dubious as first of all it detects glibc even for uClibc builds.

Even of we were to improve it, there seems to be no users of this symbol.

$git grep HAVE_GLIBC_SUPPORT
perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc)

So I'd propose to remove it !

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
@ 2019-05-02 16:55                   ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 16:55 UTC (permalink / raw)
  To: Rich Felker, Jin Yao
  Cc: devel, Arnaldo Carvalho de Melo, Arnd Bergmann,
	Arnaldo Carvalho de Melo, lkml, linux-perf-users, Jiri Olsa,
	Namhyung Kim, arcml

On 4/30/19 8:12 PM, Rich Felker wrote:
>>> What are you trying to achieve? I was just CC'd and I'm missing the
>>> context.
>>
>> Sorry I added you as a subject matter expert but didn't provide enough context.
>>
>> The original issue [1] was perf failing to build on ARC due to perf tools needing
>> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
>> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
>> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
>> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
>>
>> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
>> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html
> 
> I think you misunderstood -- 

:-)

> I'm asking what you're trying to achieve
> by detecting whether the libc is glibc, rather than whether it has
> some particular interface you want to conditionally use. This is a
> major smell and is usually something wrong that shouldn't be done.

Good question indeed. Back in 2015 I initially ran into some quirks due to subtle
libc differences.  At the time perf has a fwd ref for strlcpy which exactly
matched glibc but not uClibc.  see commit  a83d869f300bf91 "(perf tools: Elide
strlcpy warning with uclibc)" or 0215d59b154 "(tools lib: Reinstate strlcpy()
header guard with __UCLIBC__)"

But this still used the libc defined symbol __UCLIBC__ or __GLIBC__

Your question however pertains to perf glibc feature check where perf generates an
alternate symbol HAVE_GLIBC_SUPPORT.

This is dubious as first of all it detects glibc even for uClibc builds.

Even of we were to improve it, there seems to be no users of this symbol.

$git grep HAVE_GLIBC_SUPPORT
perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc)

So I'd propose to remove it !

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
@ 2019-05-02 16:55                   ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 16:55 UTC (permalink / raw)
  To: linux-snps-arc

On 4/30/19 8:12 PM, Rich Felker wrote:
>>> What are you trying to achieve? I was just CC'd and I'm missing the
>>> context.
>>
>> Sorry I added you as a subject matter expert but didn't provide enough context.
>>
>> The original issue [1] was perf failing to build on ARC due to perf tools needing
>> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
>> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
>> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
>> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
>>
>> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
>> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html
> 
> I think you misunderstood -- 

:-)

> I'm asking what you're trying to achieve
> by detecting whether the libc is glibc, rather than whether it has
> some particular interface you want to conditionally use. This is a
> major smell and is usually something wrong that shouldn't be done.

Good question indeed. Back in 2015 I initially ran into some quirks due to subtle
libc differences.  At the time perf has a fwd ref for strlcpy which exactly
matched glibc but not uClibc.  see commit  a83d869f300bf91 "(perf tools: Elide
strlcpy warning with uclibc)" or 0215d59b154 "(tools lib: Reinstate strlcpy()
header guard with __UCLIBC__)"

But this still used the libc defined symbol __UCLIBC__ or __GLIBC__

Your question however pertains to perf glibc feature check where perf generates an
alternate symbol HAVE_GLIBC_SUPPORT.

This is dubious as first of all it detects glibc even for uClibc builds.

Even of we were to improve it, there seems to be no users of this symbol.

$git grep HAVE_GLIBC_SUPPORT
perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc)

So I'd propose to remove it !

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: perf tools build broken after v5.1-rc1
  2019-05-02 16:41                 ` Arnaldo Carvalho de Melo
@ 2019-05-02 17:10                   ` Vineet Gupta
  -1 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 17:10 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Arnd Bergmann, Rich Felker, Arnaldo Carvalho de Melo, lkml,
	linux-perf-users, Jiri Olsa, Namhyung Kim, arcml

On 5/2/19 9:41 AM, Arnaldo Carvalho de Melo wrote:
>> While this takes care of immediate issues, for the long term, are you open to idea
>> of removing the header duplicity.
>
> In the beginning we used the kernel headers directly, then, acting on
> advice/complaints from Linus about tooling breaking when changes were
> made in the kernel sources we were using directly, we moved to have
> copies and notice when things change so that we could think about what
> changed and act accordingly, without putting the burden to the kernel
> developers to keep tools/ building, I want to keep it that way.

Sure, and the reduced duplicity I propose doesn't change that in any way. The onus
is still on perf maintainers to copy over any unistd changes - in the new regime,
it will be just lesser since we only care about a handful of syscalls, not the
entire unistd.


> Now you say, validly, that there are bits that are designed to be used
> by userspace, so for those, we should go back to not copying and using
> it direcly, elliminating the duplicity you don't like.

Indeed.

> I don't know, I'm used to the duplicity and the checks,

:-)

> not breaking
> tools even when kernel developers make mistakes in the UAPI headers,

Not sure how replacing the full header with just a small hunk, out of same header
out-of-line will change anything or cause any more breakage.

> tools/perf is self container wrt the latest and greatest stuff not
> present in older environments, and the onus is on perf developers to do
> the sync.

Sure it is, I'm proposing to make their work less, no more.


> This specific issue here happened because I made a mistake, which I
> fixed when reported,

Exactly, it was a genuien mistake with a super prompt followup - your promptness
is really appreciated and emulation worthy for other maintainers including myself ;-)

> now I have three containers for cross building for
> ARC, two versions for the uCLibc based toolchain, one for the glibc one,
> libnuma, elfutils and zlib are cross build there, so should make it less
> likely problems like this will happen again.

Ok, well lets leave it at that for now then.


>> We could use a "less evil" idiom of copying only the minimal bits (since the sync
>> onus remains one way or the other)
>> e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects
>  
>> #ifdef __NR_xx
>> # if defined (__arch_y__)
>>
>> # elif defined (__arch_z__)
>>
>> # endif
>> #endif

Thx,
-Vineet

^ permalink raw reply	[flat|nested] 55+ messages in thread
* perf tools build broken after v5.1-rc1
@ 2019-05-02 17:10                   ` Vineet Gupta
  0 siblings, 0 replies; 55+ messages in thread
From: Vineet Gupta @ 2019-05-02 17:10 UTC (permalink / raw)
  To: linux-snps-arc

On 5/2/19 9:41 AM, Arnaldo Carvalho de Melo wrote:
>> While this takes care of immediate issues, for the long term, are you open to idea
>> of removing the header duplicity.
>
> In the beginning we used the kernel headers directly, then, acting on
> advice/complaints from Linus about tooling breaking when changes were
> made in the kernel sources we were using directly, we moved to have
> copies and notice when things change so that we could think about what
> changed and act accordingly, without putting the burden to the kernel
> developers to keep tools/ building, I want to keep it that way.

Sure, and the reduced duplicity I propose doesn't change that in any way. The onus
is still on perf maintainers to copy over any unistd changes - in the new regime,
it will be just lesser since we only care about a handful of syscalls, not the
entire unistd.


> Now you say, validly, that there are bits that are designed to be used
> by userspace, so for those, we should go back to not copying and using
> it direcly, elliminating the duplicity you don't like.

Indeed.

> I don't know, I'm used to the duplicity and the checks,

:-)

> not breaking
> tools even when kernel developers make mistakes in the UAPI headers,

Not sure how replacing the full header with just a small hunk, out of same header
out-of-line will change anything or cause any more breakage.

> tools/perf is self container wrt the latest and greatest stuff not
> present in older environments, and the onus is on perf developers to do
> the sync.

Sure it is, I'm proposing to make their work less, no more.


> This specific issue here happened because I made a mistake, which I
> fixed when reported,

Exactly, it was a genuien mistake with a super prompt followup - your promptness
is really appreciated and emulation worthy for other maintainers including myself ;-)

> now I have three containers for cross building for
> ARC, two versions for the uCLibc based toolchain, one for the glibc one,
> libnuma, elfutils and zlib are cross build there, so should make it less
> likely problems like this will happen again.

Ok, well lets leave it at that for now then.


>> We could use a "less evil" idiom of copying only the minimal bits (since the sync
>> onus remains one way or the other)
>> e.g. I spotted below in bpf code and also seen in other ah-hoc multi arch projects
>  
>> #ifdef __NR_xx
>> # if defined (__arch_y__)
>>
>> # elif defined (__arch_z__)
>>
>> # endif
>> #endif

Thx,
-Vineet

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
  2019-05-02 16:55                   ` Vineet Gupta
  (?)
@ 2019-05-02 20:09                     ` Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 20:09 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Rich Felker, Jin Yao, Arnaldo Carvalho de Melo, devel,
	linux-perf-users, Arnaldo Carvalho de Melo, lkml, arcml,
	Arnd Bergmann, Jiri Olsa, Namhyung Kim

Em Thu, May 02, 2019 at 09:55:26AM -0700, Vineet Gupta escreveu:
> On 4/30/19 8:12 PM, Rich Felker wrote:
> >>> What are you trying to achieve? I was just CC'd and I'm missing the
> >>> context.
> >>
> >> Sorry I added you as a subject matter expert but didn't provide enough context.
> >>
> >> The original issue [1] was perf failing to build on ARC due to perf tools needing
> >> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
> >> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
> >> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
> >> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
> >>
> >> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
> >> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html
> > 
> > I think you misunderstood -- 
> 
> :-)
> 
> > I'm asking what you're trying to achieve
> > by detecting whether the libc is glibc, rather than whether it has
> > some particular interface you want to conditionally use. This is a
> > major smell and is usually something wrong that shouldn't be done.
> 
> Good question indeed. Back in 2015 I initially ran into some quirks due to subtle
> libc differences.  At the time perf has a fwd ref for strlcpy which exactly
> matched glibc but not uClibc.  see commit  a83d869f300bf91 "(perf tools: Elide
> strlcpy warning with uclibc)" or 0215d59b154 "(tools lib: Reinstate strlcpy()
> header guard with __UCLIBC__)"
> 
> But this still used the libc defined symbol __UCLIBC__ or __GLIBC__
> 
> Your question however pertains to perf glibc feature check where perf generates an
> alternate symbol HAVE_GLIBC_SUPPORT.
> 
> This is dubious as first of all it detects glibc even for uClibc builds.

 
> Even of we were to improve it, there seems to be no users of this symbol.
> 
> $git grep HAVE_GLIBC_SUPPORT
> perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
> perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc)
> 
> So I'd propose to remove it !

This is some remnant of the past, I'll check further but will end up
just ditching it altogether as you suggest :-)

[acme@quaco perf]$ find tools/ -type f | xargs grep HAVE_GLIBC_SUPPORT
tools/perf/builtin-version.c:	STATUS(HAVE_GLIBC_SUPPORT, glibc);
tools/perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
[acme@quaco perf]$

Its just this case that ends up using that feature detection program,

[acme@quaco perf]$ vim tools/perf/Makefile.config
[acme@quaco perf]$ find tools/ -type f | xargs grep feature-glibc
tools/perf/Makefile.config:    ifeq ($(feature-glibc), 1)
tools/perf/Makefile.config:ifeq ($(feature-glibc), 1)
[acme@quaco perf]$

BTW the function on it doesn't mean anything, what matters is if the
program builds or not :-)

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
@ 2019-05-02 20:09                     ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 20:09 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: devel, Rich Felker, Arnaldo Carvalho de Melo, Arnd Bergmann,
	Arnaldo Carvalho de Melo, lkml, linux-perf-users, Jin Yao,
	Jiri Olsa, Namhyung Kim, arcml

Em Thu, May 02, 2019 at 09:55:26AM -0700, Vineet Gupta escreveu:
> On 4/30/19 8:12 PM, Rich Felker wrote:
> >>> What are you trying to achieve? I was just CC'd and I'm missing the
> >>> context.
> >>
> >> Sorry I added you as a subject matter expert but didn't provide enough context.
> >>
> >> The original issue [1] was perf failing to build on ARC due to perf tools needing
> >> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
> >> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
> >> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
> >> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
> >>
> >> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
> >> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html
> > 
> > I think you misunderstood -- 
> 
> :-)
> 
> > I'm asking what you're trying to achieve
> > by detecting whether the libc is glibc, rather than whether it has
> > some particular interface you want to conditionally use. This is a
> > major smell and is usually something wrong that shouldn't be done.
> 
> Good question indeed. Back in 2015 I initially ran into some quirks due to subtle
> libc differences.  At the time perf has a fwd ref for strlcpy which exactly
> matched glibc but not uClibc.  see commit  a83d869f300bf91 "(perf tools: Elide
> strlcpy warning with uclibc)" or 0215d59b154 "(tools lib: Reinstate strlcpy()
> header guard with __UCLIBC__)"
> 
> But this still used the libc defined symbol __UCLIBC__ or __GLIBC__
> 
> Your question however pertains to perf glibc feature check where perf generates an
> alternate symbol HAVE_GLIBC_SUPPORT.
> 
> This is dubious as first of all it detects glibc even for uClibc builds.

 
> Even of we were to improve it, there seems to be no users of this symbol.
> 
> $git grep HAVE_GLIBC_SUPPORT
> perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
> perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc)
> 
> So I'd propose to remove it !

This is some remnant of the past, I'll check further but will end up
just ditching it altogether as you suggest :-)

[acme@quaco perf]$ find tools/ -type f | xargs grep HAVE_GLIBC_SUPPORT
tools/perf/builtin-version.c:	STATUS(HAVE_GLIBC_SUPPORT, glibc);
tools/perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
[acme@quaco perf]$

Its just this case that ends up using that feature detection program,

[acme@quaco perf]$ vim tools/perf/Makefile.config
[acme@quaco perf]$ find tools/ -type f | xargs grep feature-glibc
tools/perf/Makefile.config:    ifeq ($(feature-glibc), 1)
tools/perf/Makefile.config:ifeq ($(feature-glibc), 1)
[acme@quaco perf]$

BTW the function on it doesn't mean anything, what matters is if the
program builds or not :-)

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
@ 2019-05-02 20:09                     ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 55+ messages in thread
From: Arnaldo Carvalho de Melo @ 2019-05-02 20:09 UTC (permalink / raw)
  To: linux-snps-arc

Em Thu, May 02, 2019 at 09:55:26AM -0700, Vineet Gupta escreveu:
> On 4/30/19 8:12 PM, Rich Felker wrote:
> >>> What are you trying to achieve? I was just CC'd and I'm missing the
> >>> context.
> >>
> >> Sorry I added you as a subject matter expert but didn't provide enough context.
> >>
> >> The original issue [1] was perf failing to build on ARC due to perf tools needing
> >> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
> >> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
> >> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
> >> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
> >>
> >> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
> >> [2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html
> > 
> > I think you misunderstood -- 
> 
> :-)
> 
> > I'm asking what you're trying to achieve
> > by detecting whether the libc is glibc, rather than whether it has
> > some particular interface you want to conditionally use. This is a
> > major smell and is usually something wrong that shouldn't be done.
> 
> Good question indeed. Back in 2015 I initially ran into some quirks due to subtle
> libc differences.  At the time perf has a fwd ref for strlcpy which exactly
> matched glibc but not uClibc.  see commit  a83d869f300bf91 "(perf tools: Elide
> strlcpy warning with uclibc)" or 0215d59b154 "(tools lib: Reinstate strlcpy()
> header guard with __UCLIBC__)"
> 
> But this still used the libc defined symbol __UCLIBC__ or __GLIBC__
> 
> Your question however pertains to perf glibc feature check where perf generates an
> alternate symbol HAVE_GLIBC_SUPPORT.
> 
> This is dubious as first of all it detects glibc even for uClibc builds.

 
> Even of we were to improve it, there seems to be no users of this symbol.
> 
> $git grep HAVE_GLIBC_SUPPORT
> perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
> perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc)
> 
> So I'd propose to remove it !

This is some remnant of the past, I'll check further but will end up
just ditching it altogether as you suggest :-)

[acme at quaco perf]$ find tools/ -type f | xargs grep HAVE_GLIBC_SUPPORT
tools/perf/builtin-version.c:	STATUS(HAVE_GLIBC_SUPPORT, glibc);
tools/perf/Makefile.config:  CFLAGS += -DHAVE_GLIBC_SUPPORT
[acme at quaco perf]$

Its just this case that ends up using that feature detection program,

[acme at quaco perf]$ vim tools/perf/Makefile.config
[acme at quaco perf]$ find tools/ -type f | xargs grep feature-glibc
tools/perf/Makefile.config:    ifeq ($(feature-glibc), 1)
tools/perf/Makefile.config:ifeq ($(feature-glibc), 1)
[acme at quaco perf]$

BTW the function on it doesn't mean anything, what matters is if the
program builds or not :-)

- Arnaldo

^ permalink raw reply	[flat|nested] 55+ messages in thread
* [tip:perf/urgent] tools arch uapi: Copy missing unistd.h headers for arc, hexagon and riscv
  2019-04-26 19:35         ` Arnaldo Carvalho de Melo
                           ` (2 preceding siblings ...)
  (?)
@ 2019-05-03  5:58         ` tip-bot for Arnaldo Carvalho de Melo
  -1 siblings, 0 replies; 55+ messages in thread
From: tip-bot for Arnaldo Carvalho de Melo @ 2019-05-03  5:58 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: tglx, hpa, arnd, acme, namhyung, linux-kernel, jolsa,
	adrian.hunter, Vineet.Gupta1, mingo

Commit-ID:  18f90d372cf35b387663f1567de701e5393f6eb5
Gitweb:     https://git.kernel.org/tip/18f90d372cf35b387663f1567de701e5393f6eb5
Author:     Arnaldo Carvalho de Melo <acme@redhat.com>
AuthorDate: Mon, 22 Apr 2019 15:21:35 -0300
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Thu, 2 May 2019 16:00:20 -0400

tools arch uapi: Copy missing unistd.h headers for arc, hexagon and riscv

Since those were introduced in:

  c8ce48f06503 ("asm-generic: Make time32 syscall numbers optional")

But when the asm-generic/unistd.h was sync'ed with tools/ in:

  1a787fc5ba18 ("tools headers uapi: Sync copy of asm-generic/unistd.h with the kernel sources")

I forgot to copy the files for the architectures that define
__ARCH_WANT_TIME32_SYSCALLS, so the perf build was breaking there, as
reported by Vineet Gupta for the ARC architecture.

After updating my ARC container to use the glibc based toolchain + cross
building libnuma, zlib and elfutils, I finally managed to reproduce the
problem and verify that this now is fixed and will not regress as will
be tested before each pull req sent upstream.

Reported-by: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jiri Olsa <jolsa@kernel.org>
CC: linux-snps-arc@lists.infradead.org
Cc: Namhyung Kim <namhyung@kernel.org>
Link: https://lkml.kernel.org/r/20190426193531.GC28586@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 {arch => tools/arch}/arc/include/uapi/asm/unistd.h     | 0
 {arch => tools/arch}/hexagon/include/uapi/asm/unistd.h | 0
 {arch => tools/arch}/riscv/include/uapi/asm/unistd.h   | 0
 3 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/arch/arc/include/uapi/asm/unistd.h b/tools/arch/arc/include/uapi/asm/unistd.h
similarity index 100%
copy from arch/arc/include/uapi/asm/unistd.h
copy to tools/arch/arc/include/uapi/asm/unistd.h
diff --git a/arch/hexagon/include/uapi/asm/unistd.h b/tools/arch/hexagon/include/uapi/asm/unistd.h
similarity index 100%
copy from arch/hexagon/include/uapi/asm/unistd.h
copy to tools/arch/hexagon/include/uapi/asm/unistd.h
diff --git a/arch/riscv/include/uapi/asm/unistd.h b/tools/arch/riscv/include/uapi/asm/unistd.h
similarity index 100%
copy from arch/riscv/include/uapi/asm/unistd.h
copy to tools/arch/riscv/include/uapi/asm/unistd.h

^ permalink raw reply	[flat|nested] 55+ messages in thread
end of thread, other threads:[~2019-05-03  5:58 UTC | newest]

Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-19 23:32 perf tools build broken after v5.1-rc1 Vineet Gupta
2019-04-19 23:32 ` Vineet Gupta
2019-04-22 15:20 ` Arnaldo Carvalho de Melo
2019-04-22 15:20   ` Arnaldo Carvalho de Melo
2019-04-25 21:48   ` Arnaldo Carvalho de Melo
2019-04-25 21:48     ` Arnaldo Carvalho de Melo
2019-04-26 19:28     ` Arnaldo Carvalho de Melo
2019-04-26 19:28       ` Arnaldo Carvalho de Melo
2019-04-26 19:35       ` Arnaldo Carvalho de Melo
2019-04-26 19:35         ` Arnaldo Carvalho de Melo
2019-04-26 19:35         ` Arnaldo Carvalho de Melo
2019-04-29 17:23         ` Vineet Gupta
2019-04-29 17:23           ` Vineet Gupta
2019-05-03  5:58         ` [tip:perf/urgent] tools arch uapi: Copy missing unistd.h headers for arc, hexagon and riscv tip-bot for Arnaldo Carvalho de Melo
2019-04-29 17:14     ` perf tools build broken after v5.1-rc1 Vineet Gupta
2019-04-29 17:14       ` Vineet Gupta
2019-04-30  1:18       ` Arnaldo Carvalho de Melo
2019-04-30  1:18         ` Arnaldo Carvalho de Melo
2019-04-30  1:18         ` Arnaldo Carvalho de Melo
2019-04-30 15:53         ` Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1) Vineet Gupta
2019-04-30 15:53           ` Vineet Gupta
2019-04-30 17:04           ` Rich Felker
2019-04-30 17:04             ` Rich Felker
2019-04-30 17:13             ` Vineet Gupta
2019-04-30 17:13               ` Vineet Gupta
2019-05-01  3:12               ` Rich Felker
2019-05-01  3:12                 ` Rich Felker
2019-05-02 16:55                 ` Vineet Gupta
2019-05-02 16:55                   ` Vineet Gupta
2019-05-02 16:55                   ` Vineet Gupta
2019-05-02 20:09                   ` Arnaldo Carvalho de Melo
2019-05-02 20:09                     ` Arnaldo Carvalho de Melo
2019-05-02 20:09                     ` Arnaldo Carvalho de Melo
2019-05-02 16:53         ` perf tools build broken after v5.1-rc1 Vineet Gupta
2019-05-02 16:53           ` Vineet Gupta
2019-04-29 17:17   ` Vineet Gupta
2019-04-29 17:17     ` Vineet Gupta
2019-04-30 16:12     ` Arnd Bergmann
2019-04-30 16:12       ` Arnd Bergmann
2019-05-01 20:41       ` Arnaldo Carvalho de Melo
2019-05-01 20:41         ` Arnaldo Carvalho de Melo
2019-05-01 21:17         ` Vineet Gupta
2019-05-01 21:17           ` Vineet Gupta
2019-05-02 14:36           ` Arnaldo Carvalho de Melo
2019-05-02 14:36             ` Arnaldo Carvalho de Melo
2019-05-02 14:36             ` Arnaldo Carvalho de Melo
2019-05-02 15:41             ` Arnaldo Carvalho de Melo
2019-05-02 15:41               ` Arnaldo Carvalho de Melo
2019-05-02 16:09             ` Vineet Gupta
2019-05-02 16:09               ` Vineet Gupta
2019-05-02 16:09               ` Vineet Gupta
2019-05-02 16:41               ` Arnaldo Carvalho de Melo
2019-05-02 16:41                 ` Arnaldo Carvalho de Melo
2019-05-02 17:10                 ` Vineet Gupta
2019-05-02 17:10                   ` Vineet Gupta

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.