All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
@ 2010-06-16  7:27 Robert Schuster
  2010-06-16  8:02 ` Graeme Gregory
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Robert Schuster @ 2010-06-16  7:27 UTC (permalink / raw)
  To: openembedded-devel


[-- Attachment #1.1: Type: text/plain, Size: 883 bytes --]

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

[-- Attachment #1.2: armel-atomic-builtins.dpatch --]
[-- Type: text/plain, Size: 11325 bytes --]

#! /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.

Index: gcc/config/arm/linux-atomic.c
===================================================================
--- gcc/config/arm/linux-atomic.c	(revision 0)
+++ gcc/config/arm/linux-atomic.c	(revision 0)
@@ -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)
Index: gcc/config/arm/t-linux-eabi
===================================================================
--- gcc/config/arm/t-linux-eabi	(revision 136167)
+++ gcc/config/arm/t-linux-eabi	(working copy)
@@ -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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16  7:27 [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions] Robert Schuster
@ 2010-06-16  8:02 ` Graeme Gregory
  2010-06-16 16:54   ` Khem Raj
  2010-06-16  8:42 ` Koen Kooi
  2010-07-07 10:23 ` Koen Kooi
  2 siblings, 1 reply; 14+ messages in thread
From: Graeme Gregory @ 2010-06-16  8:02 UTC (permalink / raw)
  To: openembedded-devel

On Wed, 16 Jun 2010 09:27:50 +0200
Robert Schuster <thebohemian@gmx.net> 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

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16  7:27 [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions] Robert Schuster
  2010-06-16  8:02 ` Graeme Gregory
@ 2010-06-16  8:42 ` Koen Kooi
  2010-06-16  9:17   ` Stefan Schmidt
  2010-07-07 10:23 ` Koen Kooi
  2 siblings, 1 reply; 14+ messages in thread
From: Koen Kooi @ 2010-06-16  8:42 UTC (permalink / raw)
  To: openembedded-devel

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

On 16-06-10 09:27, Robert Schuster 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).

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-----




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16  8:42 ` Koen Kooi
@ 2010-06-16  9:17   ` Stefan Schmidt
  2010-06-16  9:49     ` Koen Kooi
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Schmidt @ 2010-06-16  9:17 UTC (permalink / raw)
  To: openembedded-devel

Hello.

On Wed, 2010-06-16 at 10:42, Koen Kooi wrote:
> 
> 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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16  9:17   ` Stefan Schmidt
@ 2010-06-16  9:49     ` Koen Kooi
  2010-06-16 10:57       ` Robert Schuster
  0 siblings, 1 reply; 14+ messages in thread
From: Koen Kooi @ 2010-06-16  9:49 UTC (permalink / raw)
  To: openembedded-devel

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

On 16-06-10 11:17, Stefan Schmidt wrote:
> Hello.
> 
> On Wed, 2010-06-16 at 10:42, Koen Kooi wrote:
>>
>> 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.

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-----




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16  9:49     ` Koen Kooi
@ 2010-06-16 10:57       ` Robert Schuster
  0 siblings, 0 replies; 14+ messages in thread
From: Robert Schuster @ 2010-06-16 10:57 UTC (permalink / raw)
  To: openembedded-devel

[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]

Hi,

Am 16.06.2010 11:49, schrieb Koen Kooi:
> On 16-06-10 11:17, Stefan Schmidt wrote:
> > Hello.
>
> > On Wed, 2010-06-16 at 10:42, Koen Kooi wrote:
> >>
> >> 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.
>
> 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.


> 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.

> 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.

>
> regards,
>
> Koen

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


-- 
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




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16  8:02 ` Graeme Gregory
@ 2010-06-16 16:54   ` Khem Raj
  2010-06-16 16:56     ` Graeme Gregory
  0 siblings, 1 reply; 14+ messages in thread
From: Khem Raj @ 2010-06-16 16:54 UTC (permalink / raw)
  To: openembedded-devel

On Wed, Jun 16, 2010 at 1:02 AM, Graeme Gregory <dp@xora.org.uk> wrote:
> On Wed, 16 Jun 2010 09:27:50 +0200
> Robert Schuster <thebohemian@gmx.net> 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
>
> This sounds like it would require a DISTRO_PR bump on the Angstrom side

why a DISTRO_PR bump. ? Just update the libgcc

> 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
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16 16:54   ` Khem Raj
@ 2010-06-16 16:56     ` Graeme Gregory
  2010-06-16 17:12       ` Khem Raj
  0 siblings, 1 reply; 14+ messages in thread
From: Graeme Gregory @ 2010-06-16 16:56 UTC (permalink / raw)
  To: openembedded-devel

On Wed, 16 Jun 2010 09:54:07 -0700
Khem Raj <raj.khem@gmail.com> wrote:

> On Wed, Jun 16, 2010 at 1:02 AM, Graeme Gregory <dp@xora.org.uk>
> wrote:
> > On Wed, 16 Jun 2010 09:27:50 +0200
> > Robert Schuster <thebohemian@gmx.net> 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
> >
> > 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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16 16:56     ` Graeme Gregory
@ 2010-06-16 17:12       ` Khem Raj
  2010-06-17  7:09         ` Robert Schuster
  0 siblings, 1 reply; 14+ messages in thread
From: Khem Raj @ 2010-06-16 17:12 UTC (permalink / raw)
  To: openembedded-devel

On Wed, Jun 16, 2010 at 9:56 AM, Graeme Gregory <dp@xora.org.uk> wrote:
> On Wed, 16 Jun 2010 09:54:07 -0700
> Khem Raj <raj.khem@gmail.com> wrote:
>
>> On Wed, Jun 16, 2010 at 1:02 AM, Graeme Gregory <dp@xora.org.uk>
>> wrote:
>> > On Wed, 16 Jun 2010 09:27:50 +0200
>> > Robert Schuster <thebohemian@gmx.net> 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
>> >
>> > 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.

>
> Graeme
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16 17:12       ` Khem Raj
@ 2010-06-17  7:09         ` Robert Schuster
  2010-06-17  7:17           ` Robert Schuster
  2010-06-17 18:54           ` Stefan Schmidt
  0 siblings, 2 replies; 14+ messages in thread
From: Robert Schuster @ 2010-06-17  7:09 UTC (permalink / raw)
  To: openembedded-devel

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

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:
>
> 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
> 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.
>
>   
>> Graeme
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>>     
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>   



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-17  7:09         ` Robert Schuster
@ 2010-06-17  7:17           ` Robert Schuster
  2010-06-17 18:54           ` Stefan Schmidt
  1 sibling, 0 replies; 14+ messages in thread
From: Robert Schuster @ 2010-06-17  7:17 UTC (permalink / raw)
  To: openembedded-devel

[-- Attachment #1: Type: text/plain, Size: 3405 bytes --]

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:
> 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:
>   
>> 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
>   
>> 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.
>>
>>   
>>     
>>> Graeme
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>>     
>>>       
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>   
>>     
>
>   
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>   


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-17  7:09         ` Robert Schuster
  2010-06-17  7:17           ` Robert Schuster
@ 2010-06-17 18:54           ` Stefan Schmidt
  1 sibling, 0 replies; 14+ messages in thread
From: Stefan Schmidt @ 2010-06-17 18:54 UTC (permalink / raw)
  To: openembedded-devel

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

Hello.

On Thu, 2010-06-17 at 09:09, Robert Schuster wrote:
>
> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-06-16  7:27 [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions] Robert Schuster
  2010-06-16  8:02 ` Graeme Gregory
  2010-06-16  8:42 ` Koen Kooi
@ 2010-07-07 10:23 ` Koen Kooi
  2010-07-07 10:54   ` Henning Heinold
  2 siblings, 1 reply; 14+ messages in thread
From: Koen Kooi @ 2010-07-07 10:23 UTC (permalink / raw)
  To: openembedded-devel

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

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

On 16-06-10 10:42, Koen Kooi wrote:
> On 16-06-10 09:27, Robert Schuster 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).
>
> 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)

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




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions]
  2010-07-07 10:23 ` Koen Kooi
@ 2010-07-07 10:54   ` Henning Heinold
  0 siblings, 0 replies; 14+ messages in thread
From: Henning Heinold @ 2010-07-07 10:54 UTC (permalink / raw)
  To: openembedded-devel

Hi,

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

Bye Henning



^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2010-07-07 10:59 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-16  7:27 [RFC] add ubuntu patch which adds atomic builtin support to gcc 4.3.[3 but also other microversions] Robert Schuster
2010-06-16  8:02 ` Graeme Gregory
2010-06-16 16:54   ` Khem Raj
2010-06-16 16:56     ` Graeme Gregory
2010-06-16 17:12       ` Khem Raj
2010-06-17  7:09         ` Robert Schuster
2010-06-17  7:17           ` Robert Schuster
2010-06-17 18:54           ` Stefan Schmidt
2010-06-16  8:42 ` Koen Kooi
2010-06-16  9:17   ` Stefan Schmidt
2010-06-16  9:49     ` Koen Kooi
2010-06-16 10:57       ` Robert Schuster
2010-07-07 10:23 ` Koen Kooi
2010-07-07 10:54   ` Henning Heinold

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.