Skip to contentSkip to conversation

add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]

RFC In review Robert Schuster 6 participants 14 messages Jun 16, 2010 – Jul 7, 2010

lore
Share & tools
lore
#0 lore raw

RFC 1/1 add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]

Hi,
Angstrom's default GCC is 4.3.3 for ARM. Unfortunately that version lacks atomic intrinsics support for the very same architecture (__sync_synchronize and friends). The support is available from 4.4.x onwards but a patch exists in Ubuntu's GCC that adds the intrinsics to the earlier GCC version. I would like add that patch to our GCC 4.3.x (all of them so there is not suddenly a feature missing when one changes from one microversion to another). This has the potential for drastic effects on other recipes because a lot of programs (e.g. pulseaudio, llvm) check for the availability of the intrinsics and make use of them in that case.

I ask for comments here because I would also like to see this change move into OE stable later on. (The use case is to get OpenJDK with the Shark JIT compiler [llvm-based] to run on the bug20 hardware).

Regards,
Robert

#! /bin/sh -e

# DP: Atomic builtins using kernel helpers for ARM Linux/EABI.

dir=
if [ $# -eq 3 -a "$2" = '-d' ]; then

    pdir="-d $3"
    dir="$3/"

elif [ $# -ne 1 ]; then
echo >&2 "basename $0: script expects -patch|-unpatch as argument" exit 1
fi
case "$1" in

    -patch)
        patch $pdir -f --no-backup-if-mismatch -p0 < $0
        ;;
    -unpatch)
        patch $pdir -f --no-backup-if-mismatch -R -p0 < $0
        ;;
    *)
        echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
        exit 1

esac
exit 0

This patch implements the atomic builtins described at:

http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Atomic-Builtins.html

for ARM EABI Linux. This implementation uses the kernel helpers __kernel_cmpxchg and __kernel_dmb, and so should work on any architecture which supports those. (More-efficient versions are possible using ldrex/strex on architectures >=v6, but those are not written yet.)

Atomic operations are provided for data sizes of 1, 2 and 4 bytes (but not 8 bytes). The implementation uses actual functions (__sync_fetch_and_add_2, etc.) rather than expanding code inline.

Tested with cross to arm-none-linux-gnueabi, and with some additional hand-written tests which hopefully exercised the atomicity of the operations sufficiently.

OK for mainline?

Julian

ChangeLog

gcc/
* config/arm/t-linux-eabi (LIB2FUNCS_STATIC_EXTRA): Add config/arm/linux-atomic.c.
* config/arm/linux-atomic.c: New.

config/arm/linux-atomic.c +280 -0
Index: gcc/config/arm/linux-atomic.c
===================================================================
@@ -0,0 +1,280 @@
+/* Linux-specific atomic operations for ARM EABI.
+   Copyright (C) 2008 Free Software Foundation, Inc.
+   Contributed by CodeSourcery.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 2, or (at your option) any later
+version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file.  (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING.  If not, write to the Free
+Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301, USA.  */
+
+/* Kernel helper for compare-and-exchange.  */
+typedef int (__kernel_cmpxchg_t) (int oldval, int newval, int *ptr);
+#define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0xffff0fc0)
+
+/* Kernel helper for memory barrier.  */
+typedef void (__kernel_dmb_t) (void);
+#define __kernel_dmb (*(__kernel_dmb_t *) 0xffff0fa0)
+
+/* Note: we implement byte, short and int versions of atomic operations using
+   the above kernel helpers, but there is no support for "long long" (64-bit)
+   operations as yet.  */
+
+#define HIDDEN __attribute__ ((visibility ("hidden")))
+
+#ifdef __ARMEL__
+#define INVERT_MASK_1 0
+#define INVERT_MASK_2 0
+#else
+#define INVERT_MASK_1 24
+#define INVERT_MASK_2 16
+#endif
+
+#define MASK_1 0xffu
+#define MASK_2 0xffffu
+
+#define FETCH_AND_OP_WORD(OP, PFX_OP, INF_OP)				\
+  int HIDDEN								\
+  __sync_fetch_and_##OP##_4 (int *ptr, int val)				\
+  {									\
+    int failure, tmp;							\
+									\
+    do {								\
+      tmp = *ptr;							\
+      failure = __kernel_cmpxchg (tmp, PFX_OP tmp INF_OP val, ptr);	\
+    } while (failure != 0);						\
+									\
+    return tmp;								\
+  }
+
+FETCH_AND_OP_WORD (add,   , +)
+FETCH_AND_OP_WORD (sub,   , -)
+FETCH_AND_OP_WORD (or,    , |)
+FETCH_AND_OP_WORD (and,   , &)
+FETCH_AND_OP_WORD (xor,   , ^)
+FETCH_AND_OP_WORD (nand, ~, &)
+
+#define NAME_oldval(OP, WIDTH) __sync_fetch_and_##OP##_##WIDTH
+#define NAME_newval(OP, WIDTH) __sync_##OP##_and_fetch_##WIDTH
+
+/* Implement both __sync_<op>_and_fetch and __sync_fetch_and_<op> for
+   subword-sized quantities.  */
+
+#define SUBWORD_SYNC_OP(OP, PFX_OP, INF_OP, TYPE, WIDTH, RETURN)	\
+  TYPE HIDDEN								\
+  NAME##_##RETURN (OP, WIDTH) (TYPE *ptr, TYPE val)			\
+  {									\
+    int *wordptr = (int *) ((unsigned int) ptr & ~3);			\
+    unsigned int mask, shift, oldval, newval;				\
+    int failure;							\
+									\
+    shift = (((unsigned int) ptr & 3) << 3) ^ INVERT_MASK_##WIDTH;	\
+    mask = MASK_##WIDTH << shift;					\
+									\
+    do {								\
+      oldval = *wordptr;						\
+      newval = ((PFX_OP ((oldval & mask) >> shift)			\
+                 INF_OP (unsigned int) val) << shift) & mask;		\
+      newval |= oldval & ~mask;						\
+      failure = __kernel_cmpxchg (oldval, newval, wordptr);		\
+    } while (failure != 0);						\
+									\
+    return (RETURN & mask) >> shift;					\
+  }
+
+SUBWORD_SYNC_OP (add,   , +, short, 2, oldval)
+SUBWORD_SYNC_OP (sub,   , -, short, 2, oldval)
+SUBWORD_SYNC_OP (or,    , |, short, 2, oldval)
+SUBWORD_SYNC_OP (and,   , &, short, 2, oldval)
+SUBWORD_SYNC_OP (xor,   , ^, short, 2, oldval)
+SUBWORD_SYNC_OP (nand, ~, &, short, 2, oldval)
+
+SUBWORD_SYNC_OP (add,   , +, char, 1, oldval)
+SUBWORD_SYNC_OP (sub,   , -, char, 1, oldval)
+SUBWORD_SYNC_OP (or,    , |, char, 1, oldval)
+SUBWORD_SYNC_OP (and,   , &, char, 1, oldval)
+SUBWORD_SYNC_OP (xor,   , ^, char, 1, oldval)
+SUBWORD_SYNC_OP (nand, ~, &, char, 1, oldval)
+
+#define OP_AND_FETCH_WORD(OP, PFX_OP, INF_OP)				\
+  int HIDDEN								\
+  __sync_##OP##_and_fetch_4 (int *ptr, int val)				\
+  {									\
+    int tmp, failure;							\
+									\
+    do {								\
+      tmp = *ptr;							\
+      failure = __kernel_cmpxchg (tmp, PFX_OP tmp INF_OP val, ptr);	\
+    } while (failure != 0);						\
+									\
+    return PFX_OP tmp INF_OP val;					\
+  }
+
+OP_AND_FETCH_WORD (add,   , +)
+OP_AND_FETCH_WORD (sub,   , -)
+OP_AND_FETCH_WORD (or,    , |)
+OP_AND_FETCH_WORD (and,   , &)
+OP_AND_FETCH_WORD (xor,   , ^)
+OP_AND_FETCH_WORD (nand, ~, &)
+
+SUBWORD_SYNC_OP (add,   , +, short, 2, newval)
+SUBWORD_SYNC_OP (sub,   , -, short, 2, newval)
+SUBWORD_SYNC_OP (or,    , |, short, 2, newval)
+SUBWORD_SYNC_OP (and,   , &, short, 2, newval)
+SUBWORD_SYNC_OP (xor,   , ^, short, 2, newval)
+SUBWORD_SYNC_OP (nand, ~, &, short, 2, newval)
+
+SUBWORD_SYNC_OP (add,   , +, char, 1, newval)
+SUBWORD_SYNC_OP (sub,   , -, char, 1, newval)
+SUBWORD_SYNC_OP (or,    , |, char, 1, newval)
+SUBWORD_SYNC_OP (and,   , &, char, 1, newval)
+SUBWORD_SYNC_OP (xor,   , ^, char, 1, newval)
+SUBWORD_SYNC_OP (nand, ~, &, char, 1, newval)
+
+int HIDDEN
+__sync_val_compare_and_swap_4 (int *ptr, int oldval, int newval)
+{
+  int actual_oldval, fail;
+    
+  while (1)
+    {
+      actual_oldval = *ptr;
+
+      if (oldval != actual_oldval)
+	return actual_oldval;
+
+      fail = __kernel_cmpxchg (actual_oldval, newval, ptr);
+  
+      if (!fail)
+        return oldval;
+    }
+}
+
+#define SUBWORD_VAL_CAS(TYPE, WIDTH)					\
+  TYPE HIDDEN								\
+  __sync_val_compare_and_swap_##WIDTH (TYPE *ptr, TYPE oldval,		\
+				       TYPE newval)			\
+  {									\
+    int *wordptr = (int *)((unsigned int) ptr & ~3), fail;		\
+    unsigned int mask, shift, actual_oldval, actual_newval;		\
+									\
+    shift = (((unsigned int) ptr & 3) << 3) ^ INVERT_MASK_##WIDTH;	\
+    mask = MASK_##WIDTH << shift;					\
+									\
+    while (1)								\
+      {									\
+	actual_oldval = *wordptr;					\
+									\
+	if (((actual_oldval & mask) >> shift) != (unsigned int) oldval)	\
+          return (actual_oldval & mask) >> shift;			\
+									\
+	actual_newval = (actual_oldval & ~mask)				\
+			| (((unsigned int) newval << shift) & mask);	\
+									\
+	fail = __kernel_cmpxchg (actual_oldval, actual_newval,		\
+				 wordptr);				\
+									\
+	if (!fail)							\
+          return oldval;						\
+      }									\
+  }
+
+SUBWORD_VAL_CAS (short, 2)
+SUBWORD_VAL_CAS (char,  1)
+
+typedef unsigned char bool;
+
+bool HIDDEN
+__sync_bool_compare_and_swap_4 (int *ptr, int oldval, int newval)
+{
+  int failure = __kernel_cmpxchg (oldval, newval, ptr);
+  return (failure == 0);
+}
+
+#define SUBWORD_BOOL_CAS(TYPE, WIDTH)					\
+  bool HIDDEN								\
+  __sync_bool_compare_and_swap_##WIDTH (TYPE *ptr, TYPE oldval,		\
+					TYPE newval)			\
+  {									\
+    TYPE actual_oldval							\
+      = __sync_val_compare_and_swap_##WIDTH (ptr, oldval, newval);	\
+    return (oldval == actual_oldval);					\
+  }
+
+SUBWORD_BOOL_CAS (short, 2)
+SUBWORD_BOOL_CAS (char,  1)
+
+void HIDDEN
+__sync_synchronize (void)
+{
+  __kernel_dmb ();
+}
+
+int HIDDEN
+__sync_lock_test_and_set_4 (int *ptr, int val)
+{
+  int failure, oldval;
+
+  do {
+    oldval = *ptr;
+    failure = __kernel_cmpxchg (oldval, val, ptr);
+  } while (failure != 0);
+
+  return oldval;
+}
+
+#define SUBWORD_TEST_AND_SET(TYPE, WIDTH)				\
+  TYPE HIDDEN								\
+  __sync_lock_test_and_set_##WIDTH (TYPE *ptr, TYPE val)		\
+  {									\
+    int failure;							\
+    unsigned int oldval, newval, shift, mask;				\
+    int *wordptr = (int *) ((unsigned int) ptr & ~3);			\
+									\
+    shift = (((unsigned int) ptr & 3) << 3) ^ INVERT_MASK_##WIDTH;	\
+    mask = MASK_##WIDTH << shift;					\
+									\
+    do {								\
+      oldval = *wordptr;						\
+      newval = (oldval & ~mask)						\
+	       | (((unsigned int) val << shift) & mask);		\
+      failure = __kernel_cmpxchg (oldval, newval, wordptr);		\
+    } while (failure != 0);						\
+									\
+    return (oldval & mask) >> shift;					\
+  }
+
+SUBWORD_TEST_AND_SET (short, 2)
+SUBWORD_TEST_AND_SET (char,  1)
+
+#define SYNC_LOCK_RELEASE(TYPE, WIDTH)					\
+  void HIDDEN								\
+  __sync_lock_release_##WIDTH (TYPE *ptr)				\
+  {									\
+    *ptr = 0;								\
+    __kernel_dmb ();							\
+  }
+
+SYNC_LOCK_RELEASE (int,   4)
+SYNC_LOCK_RELEASE (short, 2)
+SYNC_LOCK_RELEASE (char,  1)
config/arm/t-linux-eabi +2 -0
Index: gcc/config/arm/t-linux-eabi
===================================================================
@@ -12,3 +12,5 @@ LIB1ASMFUNCS := $(filter-out _dvmd_tls,$
 # Multilib the standard Linux files.  Don't include crti.o or crtn.o,
 # which are provided by glibc.
 EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o
+
+LIB2FUNCS_STATIC_EXTRA += $(srcdir)/config/arm/linux-atomic.c
#1 lore raw
Quoted 12 lines · On Wed, 16 Jun 2010 09:27:50 +0200 Robert Schuster <[email protected]> wrote:

Hi,
Angstrom's default GCC is 4.3.3 for ARM. Unfortunately that version lacks atomic intrinsics support for the very same architecture (__sync_synchronize and friends). The support is available from 4.4.x onwards but a patch exists in Ubuntu's GCC that adds the intrinsics to the earlier GCC version. I would like add that patch to our GCC 4.3.x (all of them so there is not suddenly a feature missing when one changes from one microversion to another). This has the potential for drastic effects on other recipes because a lot of programs (e.g. pulseaudio, llvm) check for the availability of the intrinsics and make use of them in that case.

Quoted 6 lines

I ask for comments here because I would also like to see this change move into OE stable later on. (The use case is to get OpenJDK with the Shark JIT compiler [llvm-based] to run on the bug20 hardware).

Regards,
Robert

This sounds like it would require a DISTRO_PR bump on the Angstrom side which I am fine with, but we need to synchronize so there are enough Angstrom developers to re-fill the feeds on bump day.

Otherwise I think this is a very good idea.

Graeme

#2 lore raw
Quoted 15 lines · Graeme Gregory
Quoted 12 lines · On Wed, 16 Jun 2010 09:27:50 +0200 Robert Schuster <[email protected]> wrote:

Hi,
Angstrom's default GCC is 4.3.3 for ARM. Unfortunately that version lacks atomic intrinsics support for the very same architecture (__sync_synchronize and friends). The support is available from 4.4.x onwards but a patch exists in Ubuntu's GCC that adds the intrinsics to the earlier GCC version. I would like add that patch to our GCC 4.3.x (all of them so there is not suddenly a feature missing when one changes from one microversion to another). This has the potential for drastic effects on other recipes because a lot of programs (e.g. pulseaudio, llvm) check for the availability of the intrinsics and make use of them in that case.

Quoted 8 lines
Quoted 6 lines

I ask for comments here because I would also like to see this change move into OE stable later on. (The use case is to get OpenJDK with the Shark JIT compiler [llvm-based] to run on the bug20 hardware).

Regards,
Robert

This sounds like it would require a DISTRO_PR bump on the Angstrom side

why a DISTRO_PR bump. ? Just update the libgcc

Quoted 12 lines

which I am fine with, but we need to synchronize so there are enough Angstrom developers to re-fill the feeds on bump day.

Otherwise I think this is a very good idea.

Graeme

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

#3 lore raw
Quoted 22 lines · On Wed, 16 Jun 2010 09:54:07 -0700 Khem Raj <[email protected]> wrote:
Quoted 20 lines · Graeme Gregory
Quoted 17 lines · On Wed, 16 Jun 2010 09:27:50 +0200 Robert Schuster <[email protected]> wrote:

Hi,
Angstrom's default GCC is 4.3.3 for ARM. Unfortunately that version lacks atomic intrinsics support for the very same architecture (__sync_synchronize and friends). The support is available from 4.4.x onwards but a patch exists in Ubuntu's GCC that adds the intrinsics to the earlier GCC version. I would like add that patch to our GCC 4.3.x (all of them so there is not suddenly a feature missing when one changes from one microversion to another). This has the potential for drastic effects on other recipes because a lot of programs (e.g. pulseaudio, llvm) check for the availability of the intrinsics and make use of them in that case.

I ask for comments here because I would also like to see this change move into OE stable later on. (The use case is to get OpenJDK with the Shark JIT compiler [llvm-based] to run on the bug20 hardware).

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

Regards,
Robert

This sounds like it would require a DISTRO_PR bump on the Angstrom side

why a DISTRO_PR bump. ? Just update the libgcc

Did you miss the "This has the potential for drastic effects..." bit?

Graeme

#4 lore raw
Quoted 28 lines · Graeme Gregory
Quoted 25 lines · On Wed, 16 Jun 2010 09:54:07 -0700 Khem Raj <[email protected]> wrote:
Quoted 23 lines · Graeme Gregory
Quoted 19 lines · On Wed, 16 Jun 2010 09:27:50 +0200 Robert Schuster <[email protected]> wrote:

Hi,
Angstrom's default GCC is 4.3.3 for ARM. Unfortunately that version lacks atomic intrinsics support for the very same architecture (__sync_synchronize and friends). The support is available from 4.4.x onwards but a patch exists in Ubuntu's GCC that adds the intrinsics to the earlier GCC version. I would like add that patch to our GCC 4.3.x (all of them so there is not suddenly a feature missing when one changes from one microversion to another). This has the potential for drastic effects on other recipes because a lot of programs (e.g. pulseaudio, llvm) check for the availability of the intrinsics and make use of them in that case.

I ask for comments here because I would also like to see this change move into OE stable later on. (The use case is to get OpenJDK with the Shark JIT compiler [llvm-based] to run on the bug20 hardware).

Regards,
Robert

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines

This sounds like it would require a DISTRO_PR bump on the Angstrom side

why a DISTRO_PR bump. ? Just update the libgcc

Did you miss the "This has the potential for drastic effects..." bit?

Those applications are working fine and they will keep working fine as long as you dont recompile them
and you make sure that libgcc is updated then whenever you rebuild an application that uses the atomic
builtins will start using them until then it should work without using them.

Maybe I am missing something it would be helpful if Robert could explain potential scenarios
where it would break precompiled binaries. I don't see it.

Quoted 8 lines

Graeme

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

#5 lore raw

Hi,
first of all. As Stefan pointed out the change was needed while working for Buglabs on OpenJDK support. So it was decided that the introduction of the mentioned GCC change is handled by Stefan Schmidt now.

But I would like to elaborate on the side-effects of the patch.

Am 16.06.2010 19:12, schrieb Khem Raj:

Quoted 7 lines

Those applications are working fine and they will keep working fine as long as you dont recompile them
and you make sure that libgcc is updated then whenever you rebuild an application that uses the atomic
builtins will start using them until then it should work without using them.

Yes, already built and shipped applications are not affected at all. It is only that when certain packages are built again with the new GCC, the package's binary
will be different although PR (and PV) did not change. The reason is that most configure scripts check
for the availability of the GCC intrinsics. If they are found they make use of it, if not they either use a different implementation (libatomic-ops for example)
or bring their own (software running on ARM Linux 2.6 can assume that the neccessary kernel helpers exist and make use of them[0]) or silently disable
multithread support (that is the case for llvm 2.7).

And already compiled software will also not magically pick up the implementation found in libgcc because:
1) it was not there before
2) I am under the impression that at least some of the builtins are actually macros and thus bits of machinecode are copied into each binary using them.

However as said. Stefan is now dealing with the issue. He has gotten two patches (one from Ubuntu, another one from the GCC 4.4 stable branch) that we needed to get things going and is most likely checking the effects they have.

Regards,
Robert

[0] - code like this can be found in many projects; search for __kernel_dmb and __kernel_cmpxchg:
http://code.google.com/p/nativeclient/source/browse/trunk/src/native_client/src/include/linux/arm/atomic_ops.h?r=857

Quoted 18 lines

Maybe I am missing something it would be helpful if Robert could explain potential scenarios
where it would break precompiled binaries. I don't see it.

Quoted 8 lines

Graeme

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

#6 lore raw

Hi,
just a few more words about the patches:

- Ubuntu ARM used it for a long time, so its tested for a while
- for x86/amd64 atomic operations intrinsics are available for a looong time, so all packages built for these arches where already under the effect of 'GCC atomic builtins are available'.

Regards,
Robert

Am 17.06.2010 09:09, schrieb Robert Schuster:

Quoted 78 lines

Hi,
first of all. As Stefan pointed out the change was needed while working for Buglabs on OpenJDK support. So it was decided that the introduction of the mentioned GCC change is handled by Stefan Schmidt now.

But I would like to elaborate on the side-effects of the patch.

Am 16.06.2010 19:12, schrieb Khem Raj:

Quoted 7 lines

Those applications are working fine and they will keep working fine as long as you dont recompile them
and you make sure that libgcc is updated then whenever you rebuild an application that uses the atomic
builtins will start using them until then it should work without using them.

Yes, already built and shipped applications are not affected at all. It is only that when certain packages are built again with the new GCC, the package's binary
will be different although PR (and PV) did not change. The reason is that most configure scripts check
for the availability of the GCC intrinsics. If they are found they make use of it, if not they either use a different implementation (libatomic-ops for example)
or bring their own (software running on ARM Linux 2.6 can assume that the neccessary kernel helpers exist and make use of them[0]) or silently disable
multithread support (that is the case for llvm 2.7).

And already compiled software will also not magically pick up the implementation found in libgcc because:
1) it was not there before
2) I am under the impression that at least some of the builtins are actually macros and thus bits of machinecode are copied into each binary using them.

However as said. Stefan is now dealing with the issue. He has gotten two patches (one from Ubuntu, another one from the GCC 4.4 stable branch) that we needed to get things going and is most likely checking the effects they have.

Regards,
Robert

[0] - code like this can be found in many projects; search for __kernel_dmb and __kernel_cmpxchg:
http://code.google.com/p/nativeclient/source/browse/trunk/src/native_client/src/include/linux/arm/atomic_ops.h?r=857

Quoted 15 lines

Maybe I am missing something it would be helpful if Robert could explain potential scenarios
where it would break precompiled binaries. I don't see it.

Quoted 9 lines

Graeme

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Quoted 6 lines

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

#7 lore raw
In reply to Robert Schuster

Hello.

Quoted 4 lines · Robert Schuster

first of all. As Stefan pointed out the change was needed while working for Buglabs on OpenJDK support. So it was decided that the introduction of the mentioned GCC change is handled by Stefan Schmidt now.

And this dude is on a vacation starting tomorrow. How perfect. :) I will be back at 27th and start to look into this. Testing with angstrom and catchup with discussions here.

regards
Stefan Schmidt

#8 lore raw
In reply to Robert Schuster

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 12 lines · Robert Schuster

Hi,
Angstrom's default GCC is 4.3.3 for ARM. Unfortunately that version lacks atomic intrinsics support for the very same architecture (__sync_synchronize and friends). The support is available from 4.4.x onwards but a patch exists in Ubuntu's GCC that adds the intrinsics to the earlier GCC version. I would like add that patch to our GCC 4.3.x (all of them so there is not suddenly a feature missing when one changes from one microversion to another). This has the potential for drastic effects on other recipes because a lot of programs (e.g. pulseaudio, llvm) check for the availability of the intrinsics and make use of them in that case.

Quoted 3 lines

I ask for comments here because I would also like to see this change move into OE stable later on. (The use case is to get OpenJDK with the Shark JIT compiler [llvm-based] to run on the bug20 hardware).

My first question: Has anyone tested it in an OE build yet? My second question: When is all that openjdk stuff you keep talking about ending up in OE? I know Henning keeps handwaving about it not being ready, but after after waiting a year, is it ever going to be deemed ready by the jalimo crew? Just merge it into OE now :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMGI6OMkyGM64RGpERAo3pAJ9teoUUA6zsD9FCkDJvUYzRuABoOwCeJVZK 15hwXUxr+DzZeiRqQ/T5Li0=
=xuWK
-----END PGP SIGNATURE-----

#9 lore raw

Hello.

Quoted 5 lines · Koen Kooi

My second question: When is all that openjdk stuff you keep talking about ending up in OE? I know Henning keeps handwaving about it not being ready, but after after waiting a year, is it ever going to be deemed ready by the jalimo crew? Just merge it into OE now :)

I can't speak for the jalimo crew but I can tell you that Tarent is currently hired by BugLabs to bring in openjdk-6 and different other things to OE dev and stable for our upcoming BugLabs stuff.

It seems to me that Robert is right now trying to bring in all the needed deps for some parts. Talking LLVM, and therefor this patch, for JIT and others. If nothing problematics happens we should have this stuff in dev (and hopefully also stable) withing the next weeks.

regards
Stefan Schmidt

#10 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 9 lines · Stefan Schmidt

Hello.

Quoted 5 lines · Koen Kooi

My second question: When is all that openjdk stuff you keep talking about ending up in OE? I know Henning keeps handwaving about it not being ready, but after after waiting a year, is it ever going to be deemed ready by the jalimo crew? Just merge it into OE now :)

Quoted 8 lines

I can't speak for the jalimo crew but I can tell you that Tarent is currently hired by BugLabs to bring in openjdk-6 and different other things to OE dev and stable for our upcoming BugLabs stuff.

It seems to me that Robert is right now trying to bring in all the needed deps for some parts. Talking LLVM, and therefor this patch, for JIT and others. If nothing problematics happens we should have this stuff in dev (and hopefully also stable) withing the next weeks.

That's great news! I did beat nss from the jalimo repo into shape and pushed it into OE, but I couldn't get any other java bits to work, sadly. Henning said I was missing the magic java incantations in angstrom and after adding those I could build things like jamvm :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMGJ4MMkyGM64RGpERAsk2AJ9fs3AgcT+B2XYy0rIk68fsItoJxwCfc7C1 LeDL3aiZlMcXcYCPYcMHMw8=
=3esD
-----END PGP SIGNATURE-----

#11 lore raw

Hi,

Am 16.06.2010 11:49, schrieb Koen Kooi:

Quoted 18 lines · Stefan Schmidt
Quoted 10 lines

Hello.

Quoted 5 lines · Koen Kooi

My second question: When is all that openjdk stuff you keep talking about ending up in OE? I know Henning keeps handwaving about it not being ready, but after after waiting a year, is it ever going to be deemed ready by the jalimo crew? Just merge it into OE now :)

I can't speak for the jalimo crew but I can tell you that Tarent is

currently

Quoted 1 line

hired by BugLabs to bring in openjdk-6 and different other things to

OE dev and

Quoted 3 lines

stable for our upcoming BugLabs stuff.

It seems to me that Robert is right now trying to bring in all the

needed deps

Quoted 8 lines
Quoted 1 line

for some parts. Talking LLVM, and therefor this patch, for JIT and

others. If

Quoted 1 line

nothing problematics happens we should have this stuff in dev (and

hopefully

Quoted 1 line

also stable) withing the next weeks.

That's great news! I did beat nss from the jalimo repo into shape and pushed it into OE,

Cool, I also saw that nspr is in oe.dev nowadays. So I removed those from the Jalimo repo.

Quoted 1 line

but I couldn't get any other java bits to work,

There is only jna and the openjdk recipes left. JNA builds but I have not a single application/library
that makes use of it by now so I cannot tell whether it actually works. (It uses libffi, so I do not expect issues).

The biggest flaw of the OpenJDK recipes atm is that there are too many of them. I would like to get rid of everything below 6b18 (the very latest) to in turn get rid of many quirks for older versions of the icedtea build system. However we are having troubles building 6b18 flawlessly right now, so fixing this has precedence.

Quoted 2 lines

sadly. Henning said I was missing the magic java incantations in angstrom and after adding those I could build things like jamvm :)

I am not sure what the problem is. Most Java stuff is in OE.dev for quite some time.

Quoted 4 lines

regards,

Koen

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Signature · 12 lines
Besuchen Sie uns vom 09.06. bis zum 12.06. auf dem LinuxTag 2010
an unserem Stand „Fairtrade Software“ (Halle 7.2a. / Stand 123)!
⇒ Unsere Themen dieses Jahr ⇒ • Evolvis • Freedroidz • Portale •
• Identity and Access Management • Mobile Applikationen •

tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
Geschäftsführer: Boris Esser, Elmar Geese
HRB AG Bonn 5168 - Ust-ID: DE122264941
http://www.tarent.com/

Heilsbachstr. 24, 53123 Bonn, fon +49 228 52675-0, fax +49 228 52675-25
Weigandufer 45, 12059 Berlin, fon +49 30 5682943-30, fax +49 228 52675-25
#12 lore raw
In reply to Robert Schuster

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Any update on this? I have suddenly found a need for this patch :)

Quoted 23 lines · Koen Kooi
Quoted 12 lines · Robert Schuster

Hi,
Angstrom's default GCC is 4.3.3 for ARM. Unfortunately that version lacks atomic intrinsics support for the very same architecture (__sync_synchronize and friends). The support is available from 4.4.x onwards but a patch exists in Ubuntu's GCC that adds the intrinsics to the earlier GCC version. I would like add that patch to our GCC 4.3.x (all of them so there is not suddenly a feature missing when one changes from one microversion to another). This has the potential for drastic effects on other recipes because a lot of programs (e.g. pulseaudio, llvm) check for the availability of the intrinsics and make use of them in that case.

Quoted 3 lines

I ask for comments here because I would also like to see this change move into OE stable later on. (The use case is to get OpenJDK with the Shark JIT compiler [llvm-based] to run on the bug20 hardware).

My first question: Has anyone tested it in an OE build yet? My second question: When is all that openjdk stuff you keep talking about ending up in OE? I know Henning keeps handwaving about it not being ready, but after after waiting a year, is it ever going to be deemed ready by the jalimo crew? Just merge it into OE now :)

Quoted 3 lines

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMNFWjMkyGM64RGpERAiWuAJ9roOOUFIganNclxyYNYnTB4wpSqACdGUeR lxU/YdJzDu3iq53jZYlpE8k=
=mIiK
-----END PGP SIGNATURE-----

#13 lore raw

Hi,

I am working on it. I am right now testing if the patches applies to all gcc-4.3 versions.

Bye Henning