| Message ID | 20210508222419.586915-1-fhunleth@troodon-software.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/1] erlang: support builds when gcc __atomic_* exist | expand |
On Sat, 8 May 2021 18:24:19 -0400 Frank Hunleth <fhunleth@troodon-software.com> wrote: > While Erlang will use it's own atomic operations, it can also use gcc > __atomic_* builtins. This is now listed in Erlang's HOWTO/INSTALL.md. > > This change was necessary on RISC-V, since Erlang didn't have a built-in > implementation, but it was able to use gcc's __atomic_* functions. > > Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com> > --- > package/erlang/Config.in | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) Thanks Frank for the patch. I have applied to master. However, I think the patch may be incomplete. Indeed, on some CPU architectures, the atomic intrinsics are implemented in a separate library provided by gcc, called libatomic, and one need to link against it to use those intrinsics. Could you try to do a build of Erlang on SPARCv8 for example ? I suppose it will fail, and if it does, could you add some logic in erlang.mk to link against libatomic when BR2_TOOLCHAIN_HAS_LIBATOMIC=y (of course assuming the Erlang build system doesn't do that by itself, of course). Thanks! Thomas
Hi Thomas, On Wed, Jul 28, 2021 at 5:35 PM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > On Sat, 8 May 2021 18:24:19 -0400 > Frank Hunleth <fhunleth@troodon-software.com> wrote: > > > While Erlang will use it's own atomic operations, it can also use gcc > > __atomic_* builtins. This is now listed in Erlang's HOWTO/INSTALL.md. > > > > This change was necessary on RISC-V, since Erlang didn't have a built-in > > implementation, but it was able to use gcc's __atomic_* functions. > > > > Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com> > > --- > > package/erlang/Config.in | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > Thanks Frank for the patch. I have applied to master. However, I think > the patch may be incomplete. Indeed, on some CPU architectures, the > atomic intrinsics are implemented in a separate library provided by > gcc, called libatomic, and one need to link against it to use those > intrinsics. > > Could you try to do a build of Erlang on SPARCv8 for example ? > > I suppose it will fail, and if it does, could you add some logic in > erlang.mk to link against libatomic when BR2_TOOLCHAIN_HAS_LIBATOMIC=y > (of course assuming the Erlang build system doesn't do that by itself, > of course). As you expected, a SPARCv8 build fails. I updated erlang.mk to pass linker flags to link to libatomic, but still received errors. The errors were of type: /tmp/cc1Mog0n.s:230: Error: Architecture mismatch on "cas [%g3],%g2,%g1". /tmp/cc1Mog0n.s:230: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is v8.) I ran out of time this morning to track this down (sorry), but it's sounding like Erlang is doing something that's not causing function calls into libatomic. Right now, I'm thinking that trying to be more generic about what platforms Erlang supports may not be worth it. I.e., change this: default y if BR2_i386 || BR2_x86_64 || BR2_powerpc || \ BR2_sparc_v9 || BR2_arm || BR2_aarch64 || BR2_mipsel || \ BR2_TOOLCHAIN_HAS_ATOMIC to default y if BR2_i386 || BR2_x86_64 || BR2_powerpc || \ BR2_sparc_v9 || BR2_arm || BR2_aarch64 || BR2_mipsel || \ BR2_RISCV_64 What do you think? Thanks, Frank Thanks, Frank
On Mon, 2 Aug 2021 08:46:37 -0400 Frank Hunleth <fhunleth@troodon-software.com> wrote: > As you expected, a SPARCv8 build fails. I updated erlang.mk to pass > linker flags to link to libatomic, but still received errors. The > errors were of type: > > /tmp/cc1Mog0n.s:230: Error: Architecture mismatch on "cas [%g3],%g2,%g1". > /tmp/cc1Mog0n.s:230: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; > requested architecture is v8.) > > I ran out of time this morning to track this down (sorry), but it's > sounding like Erlang is doing something that's not causing function > calls into libatomic. > > Right now, I'm thinking that trying to be more generic about what > platforms Erlang supports may not be worth it. I.e., change this: > > default y if BR2_i386 || BR2_x86_64 || BR2_powerpc || \ > BR2_sparc_v9 || BR2_arm || BR2_aarch64 || BR2_mipsel || \ > BR2_TOOLCHAIN_HAS_ATOMIC > > to > > default y if BR2_i386 || BR2_x86_64 || BR2_powerpc || \ > BR2_sparc_v9 || BR2_arm || BR2_aarch64 || BR2_mipsel || \ > BR2_RISCV_64 > > What do you think? I'm fine with that. Note that it's also causing problems on other CPU architectures: http://autobuild.buildroot.net/?reason=erlang% You will however see that even on ARM64 there are some failures in erlang-jiffy. Best regards, Thomas
diff --git a/package/erlang/Config.in b/package/erlang/Config.in index ab87eab6ff..b6b100f38b 100644 --- a/package/erlang/Config.in +++ b/package/erlang/Config.in @@ -6,9 +6,11 @@ config BR2_PACKAGE_HOST_ERLANG_ARCH_SUPPORTS config BR2_PACKAGE_ERLANG_ARCH_SUPPORTS bool # see HOWTO/INSTALL.md for Erlang's supported platforms - # when using its native atomic ops implementation + # when using its native atomic ops implementation or gcc's + # __atomic_* builtins default y if BR2_i386 || BR2_x86_64 || BR2_powerpc || \ - BR2_sparc_v9 || BR2_arm || BR2_aarch64 || BR2_mipsel + BR2_sparc_v9 || BR2_arm || BR2_aarch64 || BR2_mipsel || \ + BR2_TOOLCHAIN_HAS_ATOMIC # erlang needs host-erlang depends on BR2_PACKAGE_HOST_ERLANG_ARCH_SUPPORTS
While Erlang will use it's own atomic operations, it can also use gcc __atomic_* builtins. This is now listed in Erlang's HOWTO/INSTALL.md. This change was necessary on RISC-V, since Erlang didn't have a built-in implementation, but it was able to use gcc's __atomic_* functions. Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com> --- package/erlang/Config.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)