[erlang-questions] Erlang on 64-bit ARM?

[Frank Hunleth]

On Mon, Jan 18, 2016 at 4:55 AM, Rickard Green <rickard@REDACTED> wrote:
> On Sun, Jan 17, 2016 at 2:38 AM, Frank Hunleth
> <fhunleth@REDACTED> wrote:
>> I was wondering if anyone uses Erlang on a 64-bit ARM platform
>> (aarch64)? The Buildroot project's CI servers are throwing linker
>> errors such as the following:
>>
>>  LD /home/buildroot/autobuild/run/instance-0/output/build/erlang-17.5/bin/aarch64-buildroot-linux-gnu/child_setup
>>  AR /home/buildroot/autobuild/run/instance-0/output/build/erlang-17.5/erts/emulator/pcre/obj/aarch64-buildroot-linux-gnu/opt/libepcre.a
>>  LD /home/buildroot/autobuild/run/instance-0/output/build/erlang-17.5/bin/aarch64-buildroot-linux-gnu/beam
>> ../lib/internal/aarch64-buildroot-linux-gnu/libethread.a(ethr_atomics.o):
>> In function `AO_double_compare_and_swap':
>> ethr_atomics.c:(.text+0x20): undefined reference to
>> `__atomic_compare_exchange_16'
>> ../lib/internal/aarch64-buildroot-linux-gnu/libethread.a(ethr_atomics.o):
>> In function `AO_double_load':
>> ethr_atomics.c:(.text+0x3c): undefined reference to `__atomic_load_16'
>> ../lib/internal/aarch64-buildroot-linux-gnu/libethread.a(ethr_atomics.o):
>> In function `ethr_dw_atomic_cmpxchg_acqb':
>> ethr_atomics.c:(.text+0x5e8): undefined reference to `__atomic_load_16'
>>
>> See http://autobuild.buildroot.net/results/0cd/0cd22eb74fa29e5a85bf897762e16ab3daf33962/build-end.log
>> for all of the error messages.
>>
>> I was able to reproduce the same errors on the 18.2.1 release as well.
>> Possibly confounding the situation is that Buildroot crosscompiles
>> Erlang. However, Erlang builds fine on all other platforms supported
>> by Buildroot, and my attempt at reading the atomic intrinsics code was
>> leading me down the path that aarch64 may not be supported. Could
>> somewhere verify whether this is the case?
>>
>> Thanks,
>> Frank
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> We unfortunately currently do not have an aarch64 machine here at OTP,
> so we have not tried to build on this arch.

Same here. I'm using qemu to investigate this issue for Buildroot.

> If you have a reasonably new gcc (at least 4.7 depending on arch)
> supporting the __atomic_* builtins these will be detected and used
> automatically when building OTP 18. If this is the case, you don't
> need libatomic_ops. If your gcc only supports __sync_* builtins, you
> want to use libatomic_ops instead. This since the __sync_* builtins
> issue unnecessary memory barriers.

Ok. I think there may be some confusion in Buildroot when
libatomic_ops is necessary. The result is that --with-libatomic_ops
was passed to ./configure on all platforms. It sounds like that logic
is incorrect, and it would be better to not use libatomic_ops unless a
platform/gcc version only works if it is available. Is this true?

>
> What does "erlang:system_info(ethread_info)" return if you build
> without libatomic_ops?

1> erlang:system_info(ethread_info).
[{"32-bit native atomics","gcc_atomic_and_sync_builtins",
  ["ethr_native_atomic32_or_retold()",
   "ethr_native_atomic32_and_retold()",
   "ethr_native_atomic32_read()",
   "ethr_native_atomic32_add_return()",
   "ethr_native_atomic32_set()",
   "ethr_native_atomic32_cmpxchg()"]},
 {"64-bit native atomics","gcc_atomic_and_sync_builtins",
  ["ethr_native_atomic64_or_retold()",
   "ethr_native_atomic64_and_retold()",
   "ethr_native_atomic64_read()",
   "ethr_native_atomic64_add_return()",
   "ethr_native_atomic64_set()",
   "ethr_native_atomic64_cmpxchg()"]},
 {"Double word native atomics","no",[]},
 {"Native spinlocks","pthread"},
 {"Native rw-spinlocks","native-atomics"}]

Thanks,
Frank
>
> Regards,
> Rickard
> --
> Rickard Green, Erlang/OTP, Ericsson AB