Does orbit support arm64 platform?

[simpzan]

I want to use this tool to analyze arm64 linux and android. I tried to build orbit on arm64 linux, it failed with the following error.

    g++-9: error: unrecognized command line option '-m64’
make[1]: *** [CMakeFiles/cmTC_d5ce4.dir/build.make:66: CMakeFiles/cmTC_d5ce4.dir/testCXXCompiler.cxx.o] Error 1
make[1]: Leaving directory
'/home/xxx/.conan/data/abseil/20220623.0/_/_/build/6eeea3904f53d9f7311f5a5b447089286767e0b4/build/RelWithDebInfo/CMakeFiles/CMakeTmp'

[florian-kuebler]

Hi, thanks for reaching out.
Profiling arm64 linux and android targets are currently not (explicitly) supported, neither do we test building form arm64.

For arm64 linux:
As we are relying mostly on Linux's perf_event_open syscall, many features should work out-of-the box (not tested). However, there are a couple of places where we explicitly assume x86_64 in the code. User-space dynamic instrumentation, disassembly view, frame-pointer-based unwinding, will certainly not work.

For android:
We use android's unwinding library libunwindstack, which does support mixed Java/native callstack unwinding. However, we currently have no code in place, to retrieve Java's symbol information. Also neither dynamic nor manual instrumentation will work on Java code, and we would need to have some custom solution (e.g. using aspectj, or some dynamic analysis technique). There might be also other obstacles I am currently not aware of.

So depending on the needs, it might be not too much effort to get it working. Sophisticated support is for sure quite some work.

We don't have any resources right now, to look into this, but contributions are more then welcome. If needed, I can provide necessary code-pointers to get started.

As an alternative, you might want to consider perfetto, which is explicitly developed for android.

[simpzan]

Thanks for timely response.

Currently I am most interested in native user-space dynamic instrumentation on arm64. perfetto doesn't seem to support this feature.
arm64 devices are getting more and more popular, it would be great if at least the collector component can work on arm64, so that we can use x86_64 desktop as frontend to remotely instrument arm64 devices.

[florian-kuebler]

I see. I am also not aware that perfetto has support for dynamic instrumentation.

So the user-space dynamic instrumentation actually contains a bunch of hand-written machine code and has many assumptions that the target-platform is x86_64. Adding support for arm64 feels like a very huge project.

However, we also support dynamic instrumentation based on Linux's uprobe mechanism (still instrumenting user-space functions, but going through the kernel, which is around 10x slower, but might be sufficient). As this is baked into the kernel, I am pretty confident that it has arm64 support, and it might even work out-of-the-box in Orbit.

[florian-kuebler]

Note: It obviously assumes, that the android kernel is build with uprobe support, and that it is possible to run the collector with necessary permissions.

[florian-kuebler]

@beckerhe might now more about the compilation error (where we pass the "-m64").

[beckerhe]

The -m64 flag is probably generated by Conan. How does your Conan profile look like?

[simpzan]

I am not aware of Conan profile. I just followed the doc and used bootstrap-orbit.sh to build it.

[sponsoredlinks]

In case anyone finds their way here with the same problem, the reason for the -m64 appears to be that the conan default_release profile is being used by default

Note: not claiming orbit is supported on arm etc - purely how to fix this error, as for someone unfamiliar with conan how this worked wasn't immediately obvious to me

On my arm board (rpi5) this profile was being detected (or was being set by something in the orbit build) incorrectly as x86_64 which caused the corresponding -m64 flag to be passed to the abseil build

To fix it:

• delete the default_release profile (may exist elsewhere)

rm /home/user/.conan/profiles/default_release

• recreate it in-place

conan profile new --detect default_release

• Then when prompted about old abi compatibility:

conan profile update settings.compiler.libcxx=libstdc++11 default_release

Check your profile is now correct

~/orbit $ conan profile show default_release
Configuration for profile default_release:

[settings]
os=Linux
os_build=Linux
arch=armv8
arch_build=armv8
compiler=gcc
compiler.version=12
compiler.libcxx=libstdc++11
build_type=Release
[options]
[conf]
[build_requires]
[env]

For me abseil then builds happily without complaint when I ./bootstrap-orbit.sh