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

[Rickard Green]

On Mon, Jan 18, 2016 at 10:32 PM, Frank Hunleth
<fhunleth@REDACTED> wrote:
> 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?
>

Yes, I think so.

>>
>> 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"}]
>

It is using the __atomic_* builtins, so no need for libatomic_ops.

Regards,
Rickard

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

-- 
Rickard Green, Erlang/OTP, Ericsson AB