As of Android NDK r15, GCC is no longer supported. Since then, the GCC
compiler has been phased out in the NDK, and LLVM/Clang became the
official toolchain.

However, the document android.txt contains steps for cross building Perf
with GCC with using an older NDK. On the other hand, It is problematic
for Perf cross building with Clang - multiple compilation errors and
missing dependency libraries are observed.

Thus, mark the Documentation/android.txt as obsolete. This file is kept
for the historical reference.

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/perf/Documentation/android.txt | 79 +---------------------------
 1 file changed, 1 insertion(+), 78 deletions(-)

diff --git a/tools/perf/Documentation/android.txt b/tools/perf/Documentation/android.txt
index 24a59998fc91..2254d0483bf4 100644
--- a/tools/perf/Documentation/android.txt
+++ b/tools/perf/Documentation/android.txt
@@ -1,78 +1 @@
-How to compile perf for Android
-=========================================
-
-I. Set the Android NDK environment
-------------------------------------------------
-
-(a). Use the Android NDK
-------------------------------------------------
-1. You need to download and install the Android Native Development Kit (NDK).
-Set the NDK variable to point to the path where you installed the NDK:
-  export NDK=/path/to/android-ndk
-
-2. Set cross-compiling environment variables for NDK toolchain and sysroot.
-For arm:
-  export NDK_TOOLCHAIN=${NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-
-  export NDK_SYSROOT=${NDK}/platforms/android-24/arch-arm
-For x86:
-  export NDK_TOOLCHAIN=${NDK}/toolchains/x86-4.9/prebuilt/linux-x86_64/bin/i686-linux-android-
-  export NDK_SYSROOT=${NDK}/platforms/android-24/arch-x86
-
-This method is only tested for Android NDK versions Revision 11b and later.
-perf uses some bionic enhancements that are not included in prior NDK versions.
-You can use method (b) described below instead.
-
-(b). Use the Android source tree
------------------------------------------------
-1. Download the master branch of the Android source tree.
-Set the environment for the target you want using:
-  source build/envsetup.sh
-  lunch
-
-2. Build your own NDK sysroot to contain latest bionic changes and set the
-NDK sysroot environment variable.
-  cd ${ANDROID_BUILD_TOP}/ndk
-For arm:
-  ./build/tools/build-ndk-sysroot.sh --abi=arm
-  export NDK_SYSROOT=${ANDROID_BUILD_TOP}/ndk/build/platforms/android-3/arch-arm
-For x86:
-  ./build/tools/build-ndk-sysroot.sh --abi=x86
-  export NDK_SYSROOT=${ANDROID_BUILD_TOP}/ndk/build/platforms/android-3/arch-x86
-
-3. Set the NDK toolchain environment variable.
-For arm:
-  export NDK_TOOLCHAIN=${ANDROID_TOOLCHAIN}/arm-linux-androideabi-
-For x86:
-  export NDK_TOOLCHAIN=${ANDROID_TOOLCHAIN}/i686-linux-android-
-
-II. Compile perf for Android
-------------------------------------------------
-You need to run make with the NDK toolchain and sysroot defined above:
-For arm:
-  make WERROR=0 ARCH=arm CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie --sysroot=${NDK_SYSROOT}"
-For x86:
-  make WERROR=0 ARCH=x86 CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie --sysroot=${NDK_SYSROOT}"
-
-III. Install perf
------------------------------------------------
-You need to connect to your Android device/emulator using adb.
-Install perf using:
-  adb push perf /data/perf
-
-If you also want to use perf-archive you need busybox tools for Android.
-For installing perf-archive, you first need to replace #!/bin/bash with #!/system/bin/sh:
-  sed 's/#!\/bin\/bash/#!\/system\/bin\/sh/g' perf-archive >> /tmp/perf-archive
-  chmod +x /tmp/perf-archive
-  adb push /tmp/perf-archive /data/perf-archive
-
-IV. Environment settings for running perf
-------------------------------------------------
-Some perf features need environment variables to run properly.
-You need to set these before running perf on the target:
-  adb shell
-  # PERF_PAGER=cat
-
-IV. Run perf
-------------------------------------------------
-Run perf on your device/emulator to which you previously connected using adb:
-  # ./data/perf
+Android NDK compilation is deprecated and no longer supported.
-- 
2.34.1

On Mon, Jul 15, 2024 at 7:34 AM Leo Yan <leo.yan@arm.com> wrote:
[snip]
> +Android NDK compilation is deprecated and no longer supported.

I think this is objectively worse than just removing the file. It is
likely the perf tool can build with clang/LLVM, I do it every day, and
the special case for Android is likely more about the libc (aka
bionic) which gradually over time has been becoming more full fat -
perhaps we need to carry somethings in tools/include for missing
definitions, but we build with musl and that's a PITA in this regard,
we've also been reducing the tools/include dependencies for perf trace
beauty support. We don't use ifuncs in the perf tool (Android's
linker/loader historically hasn't supported these) and the weak symbol
games should be okay and something I aspire to make less in the perf
tool over time. As Android uses Linux then it should work and should
be supported.

Thanks,
Ian

On 15/07/2024 6:17 pm, Ian Rogers wrote:
> On Mon, Jul 15, 2024 at 7:34 AM Leo Yan <leo.yan@arm.com> wrote:
> [snip]
>> +Android NDK compilation is deprecated and no longer supported.
> 
> I think this is objectively worse than just removing the file. It is

Objectively worse is a bit strong. There was some discussion on the 
previous version about the reasoning, but the point is to leave keywords 
so that someone re-writing the NDK docs in the future can find it and 
then the history will be preserved rather than putting it in a new file 
with a new name. Or even someone wondering why their build command 
doesn't work has at least something documented about it, even as a negative.

Of course this all depends on whether we decide the Android build 
_should_ be working or not which looks like is also being discussed here.

> likely the perf tool can build with clang/LLVM, I do it every day, and
> the special case for Android is likely more about the libc (aka
> bionic) which gradually over time has been becoming more full fat -
> perhaps we need to carry somethings in tools/include for missing
> definitions, but we build with musl and that's a PITA in this regard,
> we've also been reducing the tools/include dependencies for perf trace
> beauty support. We don't use ifuncs in the perf tool (Android's
> linker/loader historically hasn't supported these) and the weak symbol
> games should be okay and something I aspire to make less in the perf
> tool over time. As Android uses Linux then it should work and should
> be supported.
> 
> Thanks,
> Ian

On 7/16/24 10:10, James Clark wrote:
>> On Mon, Jul 15, 2024 at 7:34 AM Leo Yan <leo.yan@arm.com> wrote:

[...]

>> I think this is objectively worse than just removing the file. It is
> 
> Objectively worse is a bit strong. There was some discussion on the
> previous version about the reasoning, but the point is to leave keywords
> so that someone re-writing the NDK docs in the future can find it and
> then the history will be preserved rather than putting it in a new file
> with a new name. Or even someone wondering why their build command
> doesn't work has at least something documented about it, even as a negative.

It is critical for the document not delivering any confusion. Keeping
the doc with a clear clarification, or deleting the useless doc, both
are much better than obsolete info.

> Of course this all depends on whether we decide the Android build
> _should_ be working or not which looks like is also being discussed here.

Yeah, I think the important thing is to get clang/LLVM cross build to
work. This is the prerequisites for using Android NDK.

Thanks,
Leo

Hi Ian,

On 7/15/24 18:17, Ian Rogers wrote:
> On Mon, Jul 15, 2024 at 7:34 AM Leo Yan <leo.yan@arm.com> wrote:
> [snip]
>> +Android NDK compilation is deprecated and no longer supported.
> 
> I think this is objectively worse than just removing the file. It is
> likely the perf tool can build with clang/LLVM, I do it every day

Just curious, are you using LLVM/clang for cross building (e.g. build
aarch64 target on x86_64 host) or just native building?

Clang/LLVM is a natively cross-compiler [1], I installed Clang-15 in the
offical package on Ubuntu, but I failed to do cross compilation with it:

   make ARCH=arm64 LLVM=-15 VF=1 DEBUG=1 -C tools/perf

> and the special case for Android is likely more about the libc (aka
> bionic) which gradually over time has been becoming more full fat -
> perhaps we need to carry somethings in tools/include for missing
> definitions, but we build with musl and that's a PITA in this regard,
> we've also been reducing the tools/include dependencies for perf trace
> beauty support. We don't use ifuncs in the perf tool (Android's
> linker/loader historically hasn't supported these) and the weak symbol
> games should be okay and something I aspire to make less in the perf
> tool over time. As Android uses Linux then it should work and should
> be supported.

Let us drop this patch.

Thanks,
Leo

[1] https://clang.llvm.org/docs/CrossCompilation.html

On Mon, Jul 15, 2024 at 12:31 PM Leo Yan <leo.yan@arm.com> wrote:
>
>
> Hi Ian,
>
> On 7/15/24 18:17, Ian Rogers wrote:
> > On Mon, Jul 15, 2024 at 7:34 AM Leo Yan <leo.yan@arm.com> wrote:
> > [snip]
> >> +Android NDK compilation is deprecated and no longer supported.
> >
> > I think this is objectively worse than just removing the file. It is
> > likely the perf tool can build with clang/LLVM, I do it every day
>
> Just curious, are you using LLVM/clang for cross building (e.g. build
> aarch64 target on x86_64 host) or just native building?
>
> Clang/LLVM is a natively cross-compiler [1], I installed Clang-15 in the
> offical package on Ubuntu, but I failed to do cross compilation with it:
>
>    make ARCH=arm64 LLVM=-15 VF=1 DEBUG=1 -C tools/perf

So we're cross-compiling in bazel, so it is a different set up than
the makefiles - I'm happy to work to share the bazel set up if other
people care. I'm having a play to see if I can get the Makefile
working, my first attempts are clearly mixing x86 code into the
supposedly arm64 build, which would appear to be more of a build
system rather than code problem.

Thanks,
Ian

On 7/15/2024 8:44 PM, Ian Rogers wrote:

[...]

> So we're cross-compiling in bazel, so it is a different set up than
> the makefiles - I'm happy to work to share the bazel set up if other
> people care. I'm having a play to see if I can get the Makefile
> working, my first attempts are clearly mixing x86 code into the
> supposedly arm64 build, which would appear to be more of a build
> system rather than code problem.

Thanks!

I don't have knowledge for Bazel build system, but it surprised me a bit that
the build system doesn't use the makefiles in Perf.

I think it is the right way to fix makefiles in Perf for cross building with
LLVM/Clang. I would like hold on the Android document updating - once the
building is fixed, we will have better knowledge for building perf on Android.

Thanks,
Leo

On Mon, Jul 15, 2024 at 12:44 PM Ian Rogers <irogers@google.com> wrote:
>
> On Mon, Jul 15, 2024 at 12:31 PM Leo Yan <leo.yan@arm.com> wrote:
> >
> >
> > Hi Ian,
> >
> > On 7/15/24 18:17, Ian Rogers wrote:
> > > On Mon, Jul 15, 2024 at 7:34 AM Leo Yan <leo.yan@arm.com> wrote:
> > > [snip]
> > >> +Android NDK compilation is deprecated and no longer supported.
> > >
> > > I think this is objectively worse than just removing the file. It is
> > > likely the perf tool can build with clang/LLVM, I do it every day
> >
> > Just curious, are you using LLVM/clang for cross building (e.g. build
> > aarch64 target on x86_64 host) or just native building?
> >
> > Clang/LLVM is a natively cross-compiler [1], I installed Clang-15 in the
> > offical package on Ubuntu, but I failed to do cross compilation with it:
> >
> >    make ARCH=arm64 LLVM=-15 VF=1 DEBUG=1 -C tools/perf
>
> So we're cross-compiling in bazel, so it is a different set up than
> the makefiles - I'm happy to work to share the bazel set up if other
> people care. I'm having a play to see if I can get the Makefile
> working, my first attempts are clearly mixing x86 code into the
> supposedly arm64 build, which would appear to be more of a build
> system rather than code problem.

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++

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

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.

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

On Mon, Jul 15, 2024 at 1:36 PM Leo Yan <leo.yan@arm.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

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?

Thanks,
Leo

On Tue, Jul 16, 2024 at 3:06 AM Leo Yan <leo.yan@arm.com> 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

On 7/16/24 14:30, Ian Rogers wrote:
> On Tue, Jul 16, 2024 at 3:06 AM Leo Yan <leo.yan@arm.com> wrote:

[...]

>> 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!

Okay, I will look into it.

> 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.

Should we follow up the steps in the Documentation/kbuild/llvm.rst?
The document uses the flag 'LLVM=1' for selecting LLVM/Clang.

Thanks,
Leo

> 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

On Tue, Jul 16, 2024 at 6:49 AM Leo Yan <leo.yan@arm.com> wrote:
>
>
> On 7/16/24 14:30, Ian Rogers wrote:
> > On Tue, Jul 16, 2024 at 3:06 AM Leo Yan <leo.yan@arm.com> wrote:
>
> [...]
>
> >> 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!
>
> Okay, I will look into it.
>
> > 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.
>
> Should we follow up the steps in the Documentation/kbuild/llvm.rst?
> The document uses the flag 'LLVM=1' for selecting LLVM/Clang.

Fix clang-built-linux email to llvm@lists.linux.dev

I'm not sure as the kernel build and the tools build differ in certain
ways. Perhaps look at the selftests build to see what they do, as they
are under tools and share the build files.

Thanks,
Ian


> Thanks,
> Leo
>
> > 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

On 7/16/2024 4:05 PM, Ian Rogers wrote:

[...]

>>> 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.
>>
>> Should we follow up the steps in the Documentation/kbuild/llvm.rst?
>> The document uses the flag 'LLVM=1' for selecting LLVM/Clang.
> 
> Fix clang-built-linux email to llvm@lists.linux.dev
> 
> I'm not sure as the kernel build and the tools build differ in certain
> ways. Perhaps look at the selftests build to see what they do, as they
> are under tools and share the build files.

Okay. thanks for suggestion.

Leo

On 15/07/2024 3:33 pm, Leo Yan wrote:
> As of Android NDK r15, GCC is no longer supported. Since then, the GCC
> compiler has been phased out in the NDK, and LLVM/Clang became the
> official toolchain.
> 
> However, the document android.txt contains steps for cross building Perf
> with GCC with using an older NDK. On the other hand, It is problematic
> for Perf cross building with Clang - multiple compilation errors and
> missing dependency libraries are observed.
> 
> Thus, mark the Documentation/android.txt as obsolete. This file is kept
> for the historical reference.
> 

Reviewed-by: James Clark <james.clark@linaro.org>

> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
>   tools/perf/Documentation/android.txt | 79 +---------------------------
>   1 file changed, 1 insertion(+), 78 deletions(-)
> 
> diff --git a/tools/perf/Documentation/android.txt b/tools/perf/Documentation/android.txt
> index 24a59998fc91..2254d0483bf4 100644
> --- a/tools/perf/Documentation/android.txt
> +++ b/tools/perf/Documentation/android.txt
> @@ -1,78 +1 @@
> -How to compile perf for Android
> -=========================================
> -
> -I. Set the Android NDK environment
> -------------------------------------------------
> -
> -(a). Use the Android NDK
> -------------------------------------------------
> -1. You need to download and install the Android Native Development Kit (NDK).
> -Set the NDK variable to point to the path where you installed the NDK:
> -  export NDK=/path/to/android-ndk
> -
> -2. Set cross-compiling environment variables for NDK toolchain and sysroot.
> -For arm:
> -  export NDK_TOOLCHAIN=${NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-
> -  export NDK_SYSROOT=${NDK}/platforms/android-24/arch-arm
> -For x86:
> -  export NDK_TOOLCHAIN=${NDK}/toolchains/x86-4.9/prebuilt/linux-x86_64/bin/i686-linux-android-
> -  export NDK_SYSROOT=${NDK}/platforms/android-24/arch-x86
> -
> -This method is only tested for Android NDK versions Revision 11b and later.
> -perf uses some bionic enhancements that are not included in prior NDK versions.
> -You can use method (b) described below instead.
> -
> -(b). Use the Android source tree
> ------------------------------------------------
> -1. Download the master branch of the Android source tree.
> -Set the environment for the target you want using:
> -  source build/envsetup.sh
> -  lunch
> -
> -2. Build your own NDK sysroot to contain latest bionic changes and set the
> -NDK sysroot environment variable.
> -  cd ${ANDROID_BUILD_TOP}/ndk
> -For arm:
> -  ./build/tools/build-ndk-sysroot.sh --abi=arm
> -  export NDK_SYSROOT=${ANDROID_BUILD_TOP}/ndk/build/platforms/android-3/arch-arm
> -For x86:
> -  ./build/tools/build-ndk-sysroot.sh --abi=x86
> -  export NDK_SYSROOT=${ANDROID_BUILD_TOP}/ndk/build/platforms/android-3/arch-x86
> -
> -3. Set the NDK toolchain environment variable.
> -For arm:
> -  export NDK_TOOLCHAIN=${ANDROID_TOOLCHAIN}/arm-linux-androideabi-
> -For x86:
> -  export NDK_TOOLCHAIN=${ANDROID_TOOLCHAIN}/i686-linux-android-
> -
> -II. Compile perf for Android
> -------------------------------------------------
> -You need to run make with the NDK toolchain and sysroot defined above:
> -For arm:
> -  make WERROR=0 ARCH=arm CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie --sysroot=${NDK_SYSROOT}"
> -For x86:
> -  make WERROR=0 ARCH=x86 CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie --sysroot=${NDK_SYSROOT}"
> -
> -III. Install perf
> ------------------------------------------------
> -You need to connect to your Android device/emulator using adb.
> -Install perf using:
> -  adb push perf /data/perf
> -
> -If you also want to use perf-archive you need busybox tools for Android.
> -For installing perf-archive, you first need to replace #!/bin/bash with #!/system/bin/sh:
> -  sed 's/#!\/bin\/bash/#!\/system\/bin\/sh/g' perf-archive >> /tmp/perf-archive
> -  chmod +x /tmp/perf-archive
> -  adb push /tmp/perf-archive /data/perf-archive
> -
> -IV. Environment settings for running perf
> -------------------------------------------------
> -Some perf features need environment variables to run properly.
> -You need to set these before running perf on the target:
> -  adb shell
> -  # PERF_PAGER=cat
> -
> -IV. Run perf
> -------------------------------------------------
> -Run perf on your device/emulator to which you previously connected using adb:
> -  # ./data/perf
> +Android NDK compilation is deprecated and no longer supported.