Re: [PATCH v2] perf docs: Mark the Android document as obsolete

From: Ian Rogers
Date: Tue Jul 16 2024 - 09:30:56 EST


On Tue, Jul 16, 2024 at 3:06 AM Leo Yan <leo.yan@xxxxxxx> wrote:
>
>
>
> On 7/15/24 22:21, Ian Rogers wrote:
>
> [...]
>
> > 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 for correcting. Now I even can build successfully with the Clang
> from Android NDK with an additional flag 'NO_DEMANGLE=1'. Though we still
> need to disable several modules for passing the building, but we are on the
> right way.
>
> Would you like to continue a formal fixing or you want me to follow up?

+clang-built-linux

If you could follow up it would be great! I'm not sure how we detect
in the build that we're using clang, I suspect there is an approach in
a different kernel Makefile/Build that already tackles this but my
quick searching didn't yield anything - perhaps the change would be
better suited to the location the CROSS_COMPILE prefix is added to
gcc. The only thing the change to Makefile.config is doing is
injecting the --target option. I'm not sure anything more is not
working for me on my laptop with this approach compared to cross
compiling with gcc, but as you say going in the right direction is
worth it anyway.

Thanks,
Ian