| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAP-5=fU=LguHNi861L4gmgZWXrrgZtG1w5cdw7hXDxnfWyJyMQ@mail.gmail.com>
Date: Mon, 15 Jul 2024 14:21:57 -0700
From: Ian Rogers <irogers@...gle.com>
To: Leo Yan <leo.yan@....com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>, "Liang, Kan" <kan.liang@...ux.intel.com>,
Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>,
Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
James Clark <james.clark@...aro.org>, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] perf docs: Mark the Android document as obsolete
On Mon, Jul 15, 2024 at 1:36 PM Leo Yan <leo.yan@....com> wrote:
>
> On 7/15/2024 9:06 PM, Ian Rogers wrote:
>
> [...]
>
> > So if I add (somewhat taken from tools/testing/selftests/lib.mk):
> > ```
> > diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> > index 5271a4c1d2b3..9edf5f41d6e4 100644
> > --- a/tools/perf/Makefile.config
> > +++ b/tools/perf/Makefile.config
> > @@ -19,6 +19,35 @@ detected_var = $(shell echo "$(1)=$($(1))" >>
> > $(OUTPUT).config-detected)
> > CFLAGS := $(EXTRA_CFLAGS) $(filter-out -Wnested-externs,$(EXTRA_WARNINGS))
> > HOSTCFLAGS := $(filter-out -Wnested-externs,$(EXTRA_WARNINGS))
> >
> > +CLANG := clang
> > +
> > +CLANG_TARGET_FLAGS_arm := arm-linux-gnueabi
> > +CLANG_TARGET_FLAGS_arm64 := aarch64-linux-gnu
> > +CLANG_TARGET_FLAGS_hexagon := hexagon-linux-musl
> > +CLANG_TARGET_FLAGS_i386 := i386-linux-gnu
> > +CLANG_TARGET_FLAGS_m68k := m68k-linux-gnu
> > +CLANG_TARGET_FLAGS_mips := mipsel-linux-gnu
> > +CLANG_TARGET_FLAGS_powerpc := powerpc64le-linux-gnu
> > +CLANG_TARGET_FLAGS_riscv := riscv64-linux-gnu
> > +CLANG_TARGET_FLAGS_s390 := s390x-linux-gnu
> > +CLANG_TARGET_FLAGS_x86 := x86_64-linux-gnu
> > +CLANG_TARGET_FLAGS_x86_64 := x86_64-linux-gnu
> > +
> > +# Default to host architecture if ARCH is not explicitly given.
> > +ifeq ($(ARCH),)
> > +CLANG_TARGET_FLAGS := $(shell $(CLANG) -print-target-triple)
> > +else
> > +CLANG_TARGET_FLAGS := $(CLANG_TARGET_FLAGS_$(ARCH))
> > +endif
> > +
> > +ifeq ($(CLANG_TARGET_FLAGS),)
> > +$(error Specify CROSS_COMPILE or add '--target=' option to lib.mk)
> > +else
> > +CLANG_FLAGS += --target=$(CLANG_TARGET_FLAGS)
> > +endif # CLANG_TARGET_FLAGS
> > +
> > +CC := $(CLANG) $(CLANG_FLAGS) -fintegrated-as
> > +
> > # Enabled Wthread-safety analysis for clang builds.
> > ifeq ($(CC_NO_CLANG), 0)
> > CFLAGS += -Wthread-safety
> > ```
> > I was able to build with:
> > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C tools/perf
> > O=/tmp/perf NO_LIBELF=1 NO_LIBTRACEEVENT=1 NO_LIBPYTHON=1 CC=clang
> > CXX=clang++
>
> This command doesn't work for me.
>
> Built with 'CROSS_COMPILE=aarch64-linux-gnu-' option, the perf tool is still
> built with GCC:
>
> $ strings perf | grep GCC
> GCC: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
>
> After removing the option 'CROSS_COMPILE=aarch64-linux-gnu-', still failed
> building.
>
> Anyway, thanks a lot for sharing.
Hmm.. I can repro but I don't see where the string comes from and my
build is definitely using clang:
```
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C tools/perf
O=/tmp/perf NO_LIBELF=1 NO_LIBTRACEEVENT=1 NO_LIBPYTHON=1 CC=clang
CXX=clang++ V=1
...
clang --target=aarch64-linux-gnu -fintegrated-as -Wbad-function-cast
-Wdeclaration-after-statement -Wformat-security -Wformat-y2k
-Winit-self -Wmissing-declarations -Wmissing-prototypes
-Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls
-Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef
-Wwrite-strings -Wformat -Wno-type-limits -Wshadow -Wthread-safety
-DHAVE_SYSCALL_TABLE_SUPPORT -I/tmp/perf/arch/arm64/include/generated
-DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET -Werror -DNDEBUG=1 -O3
-fno-omit-frame-pointer -Wall -Wextra -std=gnu11 -fstack-protector-all
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -I~/src/tools/perf/util/include
-I~/src/tools/perf/arch/arm64/include -I~/src/tools/include/
-I~/src/tools/arch/arm64/include/uapi -I~/src/tools/include/uapi
-I~/src/tools/arch/arm64/include/ -I~/src/tools/arch/arm64/
-I/tmp/perf//util -I/tmp/perf/ -I~/src/tools/perf/util
-I~/src/tools/perf -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP
-DHAVE_PTHREAD_BARRIER -DHAVE_EVENTFD_SUPPORT
-DHAVE_GET_CURRENT_DIR_NAME -DHAVE_GETTID -DHAVE_FILE_HANDLE
-DHAVE_AIO_SUPPORT -DHAVE_SCANDIRAT_SUPPORT
-DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT -DNO_LIBPERL
-DHAVE_TIMERFD_SUPPORT -DNO_LIBPYTHON -DHAVE_BACKTRACE_SUPPORT
-DHAVE_KVM_STAT_SUPPORT -DHAVE_AUXTRACE_SUPPORT
-I/tmp/perf/libapi/include -I/tmp/perf/libsubcmd/include
-I/tmp/perf/libsymbol/include -I/tmp/perf/libperf/include -I/tmp/perf/
-Wl,-z,noexecstack \
/tmp/perf/perf-in.o -Wl,--whole-archive
/tmp/perf/libapi/libapi.a /tmp/perf/libperf/libperf.a
/tmp/perf/libsubcmd/libsubcmd.a /tmp/perf/libsymbol/libsymbol.a
/tmp/perf/libperf-bench.a /tmp/perf/libperf-test.a
/tmp/perf/libperf-ui.a /tmp/perf/libperf-util.a
/tmp/perf/libpmu-events.a -Wl,--no-whole-archive -Wl,--start-group
-lpthread -lrt -lm -ldl -Wl,--end-group -o /tmp/perf/perf
$ strings /tmp/perf/perf|grep GCC
GCC: (Debian 13.2.0-13) 13.2.0
$ find /tmp/perf -name '*.[oa]' -exec sh -c "strings {} | grep GCC" \; -print
GCC: (Debian 13.2.0-13) 13.2.0
/tmp/perf/fixdep.o
GCC: (Debian 13.2.0-13) 13.2.0
/tmp/perf/fixdep-in.o
```
fixdep is being compiled with HOSTCC which isn't clang. Some more digging:
```
$ aarch64-linux-gnu-readelf -p .comment /tmp/perf/perf
String dump of section '.comment':
[ 0] GCC: (Debian 13.2.0-13) 13.2.0
[ 1f] Debian clang version 16.0.6 (20+build1)
```
So I suspect that the GCC is coming from crt0.o and that the binary
was built with clang.
Thanks,
Ian
> Leo
>
> > Obviously not a complete fix as it is unconditionally forcing CC to
> > clang, but I don't think we're too far from having a clang/llvm cross
> > compile build that can work.
> >
> > Thanks,
> > Ian
Powered by blists - more mailing lists