Message ID | 20151206151004.GA23217@waldemar-brodkorb.de |
---|---|
State | Rejected |
Headers | show |
Waldemar, On Sun, 6 Dec 2015 16:10:04 +0100, Waldemar Brodkorb wrote: > Required atomic operations not available for sparc. > Fixes autobuild failures: > http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/ > http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/ > > Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> While I agree that this would fix the problem, I am not too happy with this solution. We have lots of packages that are affected by atomic operations issues, not only on SPARC, so I'd prefer to have a better understanding of the handling of those atomic operations and add proper dependencies. For example, we have BR2_ARCH_HAS_ATOMICS. What does this Config.in option means exactly ? There are some __sync_*() builtins and __atomic_*() builtins. There is libatomic on some architectures. This is a rather big mess, and to me adding one more "depends on !BR2_sparc" is just a band-aid rather than a proper solution. Gustavo ? Thomas
Hi Thomas, Thomas Petazzoni wrote, > Waldemar, > > On Sun, 6 Dec 2015 16:10:04 +0100, Waldemar Brodkorb wrote: > > Required atomic operations not available for sparc. > > Fixes autobuild failures: > > http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/ > > http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/ > > > > Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> > > While I agree that this would fix the problem, I am not too happy with > this solution. We have lots of packages that are affected by atomic > operations issues, not only on SPARC, so I'd prefer to have a better > understanding of the handling of those atomic operations and add proper > dependencies. Sure. > For example, we have BR2_ARCH_HAS_ATOMICS. What does this Config.in > option means exactly ? It seems to declare a architecture as having atomic operations. Should we depend on BR2_ARCH_HAS_ATOMICS instead? There is another symbol for packages using libatomic_ops: BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS Interesting is that bdwgc at least is compilable for sparc. I have not done any runtime testing. But I think erlang does not only use libatomic_ops, but also they are using sync* builtins from gcc. > There are some __sync_*() builtins and __atomic_*() builtins. There is > libatomic on some architectures. GCC documentation states that _atomic_*() builtins should be used for new code. > This is a rather big mess, and to me adding one more "depends > on !BR2_sparc" is just a band-aid rather than a proper solution. Right. It seems to even get more complicated. I started hacking on leon3/leon4 support. It seems leon3/leon4 have some sparcv8 extensions, which allow to use atomic operations, so that depending on !BR2_sparc would be wrong. best regards Waldemar
Waldemar, On Sun, 6 Dec 2015 16:10:04 +0100, Waldemar Brodkorb wrote: > Required atomic operations not available for sparc. > Fixes autobuild failures: > http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/ > http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/ > > Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> > --- > package/erlang/Config.in | 2 ++ > 1 file changed, 2 insertions(+) Now that we have proper options to describe atomic intrinsics dependencies, this patch is no longer the correct solution to solve this problem. Also, there are some patches from Frank pending around erlang, touching atomic support. However, I haven't checked if they fixed the sparc issue specifically. Frank? In any case, I've marked this particular patch as Rejected. Best regards, Thomas
Hi Thomas, Waldemar, all, On Sun, Mar 6, 2016 at 6:05 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Waldemar, > > On Sun, 6 Dec 2015 16:10:04 +0100, Waldemar Brodkorb wrote: >> Required atomic operations not available for sparc. >> Fixes autobuild failures: >> http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/ >> http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/ >> >> Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> >> --- >> package/erlang/Config.in | 2 ++ >> 1 file changed, 2 insertions(+) > > Now that we have proper options to describe atomic intrinsics > dependencies, this patch is no longer the correct solution to solve > this problem. Also, there are some patches from Frank pending around > erlang, touching atomic support. However, I haven't checked if they > fixed the sparc issue specifically. No, the sparc issue isn't fixed in Erlang 18. Compilation fails with 'architecture mismatch on "cas" and "membar"' errors. Sparc_v9 works, though. My Erlang patch series had included this. It strikes me, now, that I probably should have broken the submitted patch into second commit to address sparc. I'll address that next iteration since the current submission already is greatly changed (simplified) and likely due for more comments. Regards, Frank
diff --git a/package/erlang/Config.in b/package/erlang/Config.in index 0ec01bb..4719420 100644 --- a/package/erlang/Config.in +++ b/package/erlang/Config.in @@ -2,12 +2,14 @@ comment "erlang needs a toolchain w/ dynamic library" depends on BR2_USE_MMU # fork() depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS depends on BR2_STATIC_LIBS + depends on !BR2_sparc # needs atomic operation __sync_fetch_and_add config BR2_PACKAGE_ERLANG bool "erlang" depends on BR2_USE_MMU # fork() depends on !BR2_STATIC_LIBS depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS + depends on !BR2_sparc # needs atomic operation __sync_fetch_and_add select BR2_PACKAGE_LIBATOMIC_OPS help Erlang is a programming language used to build massively scalable
Required atomic operations not available for sparc. Fixes autobuild failures: http://autobuild.buildroot.net/results/688278236e6d5bcd63b7d4413303eb115a38f3a7/ http://autobuild.buildroot.net/results/7875a7425bfe1f43d46c9a1db9f96b54f7a99b19/ Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> --- package/erlang/Config.in | 2 ++ 1 file changed, 2 insertions(+)