Re: perf tools build broken after v5.1-rc1
Em Wed, May 01, 2019 at 09:17:52PM +, 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 which for glibc includes > asm/unistd.h > uClibc OTOH #include 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 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 Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Jiri Olsa Cc: Namhyung Kim Cc: Rich Felker Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-xjpf80o64i2ko74aj2jih...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo 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 -#include #include static unsigned long flag = PERF_FLAG_FD_CLOEXEC; ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: [plat-hsdk]: Add missing multicast filter bins number to GMAC node
GMAC controller on HSDK boards supports 256 Hash Table size so we need to add the multicast filter bins property. This allows for the Hash filter to work properly using stmmac driver. Signed-off-by: Jose Abreu Cc: Joao Pinto Cc: Rob Herring Cc: Mark Rutland Cc: Vineet Gupta --- arch/arc/boot/dts/hsdk.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts index 69bc1c9e8e50..b0f059377ab0 100644 --- a/arch/arc/boot/dts/hsdk.dts +++ b/arch/arc/boot/dts/hsdk.dts @@ -187,6 +187,7 @@ interrupt-names = "macirq"; phy-mode = "rgmii"; snps,pbl = <32>; + snps,multicast-filter-bins = <256>; clocks = <&gmacclk>; clock-names = "stmmaceth"; phy-handle = <&phy0>; -- 2.7.4 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: [plat-hsdk]: Add missing multicast filter bins number to GMAC node
+CC Alexey, Eugeniy who maintain hsdk support ! On 5/2/19 8:12 AM, Jose Abreu wrote: > GMAC controller on HSDK boards supports 256 Hash Table size so we need to > add the multicast filter bins property. This allows for the Hash filter > to work properly using stmmac driver. > > Signed-off-by: Jose Abreu > Cc: Joao Pinto > Cc: Rob Herring > Cc: Mark Rutland > Cc: Vineet Gupta > --- > arch/arc/boot/dts/hsdk.dts | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts > index 69bc1c9e8e50..b0f059377ab0 100644 > --- a/arch/arc/boot/dts/hsdk.dts > +++ b/arch/arc/boot/dts/hsdk.dts > @@ -187,6 +187,7 @@ > interrupt-names = "macirq"; > phy-mode = "rgmii"; > snps,pbl = <32>; > + snps,multicast-filter-bins = <256>; > clocks = <&gmacclk>; > clock-names = "stmmaceth"; > phy-handle = <&phy0>; > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2] tools/bpf: fix perf build error with uClibc (seen on ARC)
When build perf for ARC recently, there was a build failure due to lack of __NR_bpf. | Auto-detecting system features: | | ... get_cpuid: [ OFF ] | ... bpf: [ on ] | | # error __NR_bpf not defined. libbpf does not support your arch. ^ | bpf.c: In function 'sys_bpf': | bpf.c:66:17: error: '__NR_bpf' undeclared (first use in this function) | return syscall(__NR_bpf, cmd, attr, size); | ^~~~ | sys_bpf Signed-off-by: Vineet Gupta --- v1 -> v2 - Only add syscall nr for ARC, as asm-generic won't work with arm/sh [Y Song] --- tools/lib/bpf/bpf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c index 9cd015574e83..d82edadf7589 100644 --- a/tools/lib/bpf/bpf.c +++ b/tools/lib/bpf/bpf.c @@ -46,6 +46,8 @@ # define __NR_bpf 349 # elif defined(__s390__) # define __NR_bpf 351 +# elif defined(__arc__) +# define __NR_bpf 280 # else # error __NR_bpf not defined. libbpf does not support your arch. # endif -- 2.7.4 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: perf tools build broken after v5.1-rc1
On 5/2/19 7:36 AM, Arnaldo Carvalho de Melo wrote: > Em Wed, May 01, 2019 at 09:17:52PM +, 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 which for glibc includes >> asm/unistd.h > >> uClibc OTOH #include 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 > 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 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: perf tools build broken after v5.1-rc1
Em Thu, May 02, 2019 at 10:36:18AM -0400, Arnaldo Carvalho de Melo escreveu: > Em Wed, May 01, 2019 at 09:17:52PM +, 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 which for glibc > > includes > > asm/unistd.h > > > uClibc OTOH #include 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 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: perf tools build broken after v5.1-rc1
Em Thu, May 02, 2019 at 04:09:43PM +, Vineet Gupta escreveu: > On 5/2/19 7:36 AM, Arnaldo Carvalho de Melo wrote: > > Em Wed, May 01, 2019 at 09:17:52PM +, 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 which for glibc > >> includes > >> asm/unistd.h > > > >> uClibc OTOH #include 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 > > 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 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: perf tools build broken after v5.1-rc1
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
>
> #if !defined(__UCLIBC__)
> #include
> #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?
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
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 ! ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: perf tools build broken after v5.1-rc1
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 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
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 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] tools/bpf: fix perf build error with uClibc (seen on ARC)
On Thu, May 2, 2019 at 8:57 AM Vineet Gupta wrote: > > When build perf for ARC recently, there was a build failure due to lack > of __NR_bpf. > > | Auto-detecting system features: > | > | ... get_cpuid: [ OFF ] > | ... bpf: [ on ] > | > | # error __NR_bpf not defined. libbpf does not support your arch. > ^ > | bpf.c: In function 'sys_bpf': > | bpf.c:66:17: error: '__NR_bpf' undeclared (first use in this function) > | return syscall(__NR_bpf, cmd, attr, size); > | ^~~~ > | sys_bpf > > Signed-off-by: Vineet Gupta Acked-by: Yonghong Song > --- > v1 -> v2 > - Only add syscall nr for ARC, as asm-generic won't work with arm/sh [Y > Song] > --- > tools/lib/bpf/bpf.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c > index 9cd015574e83..d82edadf7589 100644 > --- a/tools/lib/bpf/bpf.c > +++ b/tools/lib/bpf/bpf.c > @@ -46,6 +46,8 @@ > # define __NR_bpf 349 > # elif defined(__s390__) > # define __NR_bpf 351 > +# elif defined(__arc__) > +# define __NR_bpf 280 > # else > # error __NR_bpf not defined. libbpf does not support your arch. > # endif > -- > 2.7.4 > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
kisskb: OK linus/axs101_defconfig/arcompact Fri May 03, 06:56
OK linus/axs101_defconfig/arcompact Fri May 03, 06:56 http://kisskb.ellerman.id.au/kisskb/buildresult/13786932/ Commit: Merge tag 'pci-v5.1-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci b7a5b22b05472704ca3e891a3a3c7769c057413a Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4 / GNU ld (GNU Binutils) 2.23.2 No errors found in log Possible warnings (5) -- arch/arc/mm/tlb.c:914:2: warning: variable length array 'pd0' is used [-Wvla] arch/arc/include/asm/cmpxchg.h:95:29: warning: value computed is not used [-Wunused-value] net/ipv4/tcp_input.c:4315:49: warning: array subscript is above array bounds [-Warray-bounds] arch/arc/include/asm/cmpxchg.h:95:29: warning: value computed is not used [-Wunused-value] arch/arc/include/asm/cmpxchg.h:95:29: warning: value computed is not used [-Wunused-value] ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
kisskb: OK linus/axs103_smp_defconfig/arcv2 Fri May 03, 06:56
OK linus/axs103_smp_defconfig/arcv2 Fri May 03, 06:56
http://kisskb.ellerman.id.au/kisskb/buildresult/13786931/
Commit: Merge tag 'pci-v5.1-fixes-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
b7a5b22b05472704ca3e891a3a3c7769c057413a
Compiler: arc-linux-gcc.br_real (Buildroot 2016.11-git-00613-ge98b4dd) 6.2.1
20160824 / GNU ld (GNU Binutils) 2.27.51.20160928
Possible errors
---
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
Possible warnings (96)
--
kernel/dma/direct.c:40:4: warning: format '%zu' expects argument of type
'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
arch/arc/mm/tlb.c:914:2: warning: ISO C90 forbids variable length array 'pd0'
[-Wvla]
init/main.c:380:35: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
init/main.c:384:35: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
init/main.c:388:35: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
init/main.c:787:37: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type '__kernel_size_t {aka unsigned int}' [-Wformat=]
include/linux/kernel.h:827:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:827:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:827:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:827:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:827:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:827:29: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:827:29: warning: comparison of distinct pointer types
lacks a cast
drivers/base/regmap/regmap.c:1531:22: warning: format '%zu' expects argument of
type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]
drivers/base/regmap/regcache.c:719:20: warning: format '%zu' expects argument
of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
drivers/base/component.c:196:24: warning: format '%zu' expects argument of type
'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1109:35: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1124:35: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1131:35: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1137:35: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1399:17: warning: format '%zu' expects argument of type 'size_t',
but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1399:17: warning: format '%zu' expects argument of type 'size_t',
but argument 5 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
mm/percpu.c:1965:27: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1965:32: warning: format '%zu' expects argument of type 'size_t',
but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1965:37: warning: format '%zu' expects argument of type 'size_t',
but argument 5 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1965:42: warning: format '%zu' expects argument of type 'size_t',
but argument 6 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1965:52: warning: format '%zu' expects argument of type 'size_t',
but argument 7 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1965:56: warning: format '%zu' expects argument of type 'size_t',
but argument 8 has type 'unsigned int' [-Wformat=]
mm/percpu.c:2099:35: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:2105:35: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:2111:35: warning: format '%zu' expects argument of type 'size_t',
but ar
[PATCH 05/11] perf bench numa: Add define for RUSAGE_THREAD if not present
From: Arnaldo Carvalho de Melo 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 Cc: Jiri Olsa Cc: linux-snps-arc@lists.infradead.org Cc: Namhyung Kim Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/bench/numa.c | 4 1 file changed, 4 insertions(+) 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 #include +#ifndef RUSAGE_THREAD +# define RUSAGE_THREAD 1 +#endif + /* * Regular printout to the terminal, supressed if -q is specified: */ -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 10/11] tools arch uapi: Copy missing unistd.h headers for arc, hexagon and riscv
From: Arnaldo Carvalho de Melo
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
Cc: Adrian Hunter
Cc: Arnd Bergmann
Cc: Jiri Olsa
CC: linux-snps-arc@lists.infradead.org
Cc: Namhyung Kim
Link: https://lkml.kernel.org/r/20190426193531.gc28...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/arch/arc/include/uapi/asm/unistd.h | 51
tools/arch/hexagon/include/uapi/asm/unistd.h | 40 +++
tools/arch/riscv/include/uapi/asm/unistd.h | 42
3 files changed, 133 insertions(+)
create mode 100644 tools/arch/arc/include/uapi/asm/unistd.h
create mode 100644 tools/arch/hexagon/include/uapi/asm/unistd.h
create mode 100644 tools/arch/riscv/include/uapi/asm/unistd.h
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 ..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
+
+#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 ..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
+#defi
