[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Alexander Lukichev]

openpgm doesn't build correctly on AVR32 using
gcc-4.2.2-avr32-2.1.5 toolchain: it is configured to call
intrinsic atomic functions not provided by the toolchain,
so they are propagated as unresolved external symbols in the
built openpgm libraries. This breaks programs that try to link
openpgm, because they do not know where to get those either. For
instance, it breaks building zeromq tests when PGM support is
selected.

This commit disables openpgm on AVR32 due to apparent absence of
interest in this package on that architecture and it breaking too
many test builds.

Fixes http://autobuild.buildroot.net/results/5a3261109ea63ba17375003eabd8b5d88757865f/
(at least)

Signed-off-by: Alexander Lukichev <alexander.lukichev@gmail.com>
---
v2:
  - removed KConfig comment that openpgm is broken on AVR32,
    commented instead in its Config.in
  - added package name which disables PGM support for zeromq on
    AVR32
---
 package/openpgm/Config.in | 2 ++
 package/zeromq/Config.in  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/package/openpgm/Config.in b/package/openpgm/Config.in
index cae74f7..ef0f336 100644
--- a/package/openpgm/Config.in
+++ b/package/openpgm/Config.in
@@ -1,5 +1,6 @@
 config BR2_PACKAGE_OPENPGM
 	bool "openpgm"
+	depends on !BR2_avr32 # incorrectly configures for the toolchain
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	depends on BR2_INET_IPV6
 	depends on BR2_USE_WCHAR
@@ -14,3 +15,4 @@ config BR2_PACKAGE_OPENPGM
 
 comment "openpgm needs a toolchain w/ wchar, threads, IPv6"
 	depends on !(BR2_TOOLCHAIN_HAS_THREADS && BR2_INET_IPV6 && BR2_USE_WCHAR)
+	depends on !BR2_avr32
diff --git a/package/zeromq/Config.in b/package/zeromq/Config.in
index 42e13d2..a74ce88 100644
--- a/package/zeromq/Config.in
+++ b/package/zeromq/Config.in
@@ -30,6 +30,7 @@ config BR2_PACKAGE_ZEROMQ
 config BR2_PACKAGE_ZEROMQ_PGM
 	bool "PGM/EPGM support"
 	depends on BR2_PACKAGE_ZEROMQ
+	depends on !BR2_avr32 # openpgm
 	select BR2_PACKAGE_OPENPGM
 	help
 	  Add support for Pragmatic General Multicast protocol (RFC 3208)
-- 
1.8.0.1

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Thomas Petazzoni]

Dear Alexander Lukichev,

On Fri,  1 Nov 2013 20:12:28 +0200, Alexander Lukichev wrote:

> +	depends on !BR2_avr32 # incorrectly configures for the toolchain

This comment is somewhat misleading. What really happens is that
openpgm uses compiler intrinsics that did not exist in gcc 4.2. So
maybe the test should actually be on BR2_GCC_VERSION_4_2_2_AVR32_2_1_5
instead of BR2_avr32 (even though it's admittedly quite the same thing,
since AVR32 will never use any other version that this heavily patched
gcc 4.2).

I've added Simon Dawson in the CC list, who is the main contributor to
the AVR32 support in Buildroot.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Alexander Lukichev]

Hi Thomas, Simon,

The compiler (that particular toolchain) has those intrinsic functions but
is able to generate them only if the exact CPU sub architecture is
specified, not just AVR32 (their implementations differ for each of the two
sub architectures). This is impossible to specify unless we introduce it in
the buildroot configuration system (like several flavors of ARM). And this,
in turn, seems too much to make just one package happy.

I tried to disable using them in the package code by playing with
configure.ac but unsuccessfully: the code used instead some thread
functions that were not provided by the toolchain (at least, not with the
constants defined in configure). In the end, it seemed too much trouble
since nobody showed interest in the package, especially on this
architecture, and it breaks builds for AVR32.

I did not know how to explain all this concisely in openpgm's Config.in,
sorry :-)

Best regards,
  Alexander Lukichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131101/51569260/attachment.html>

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Alexander Lukichev]

Hi,

2013/11/1 Alexander Lukichev <alexander.lukichev@gmail.com>

> The compiler (that particular toolchain) has those intrinsic functions

> but is able to generate them only if the exact CPU sub architecture

> is specified, not just AVR32 (their implementations differ for each of

> the two sub architectures)
....
> I tried to disable using them in the package code by playing with
> configure.ac but unsuccessfully: the code used instead some thread
> functions that were not provided by the toolchain (at least, not with
> the constants defined in configure). In the end, it seemed too much
...
> I did not know how to explain all this concisely in openpgm's Config.in,
> sorry :-)

So, since in both cases the project was configured incorrectly for building
by
that toolchain, the comment I have put in Config.in did not seem misleading
to me.

--
Best regards,
  Alexander Lukichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131102/0f799aa4/attachment.html>

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Simon Dawson]

Hi Alexander.

On 1 November 2013 20:21, Alexander Lukichev
<alexander.lukichev@gmail.com> wrote:
> The compiler (that particular toolchain) has those intrinsic functions but
> is able to generate them only if the exact CPU sub architecture is
> specified, not just AVR32 (their implementations differ for each of the two
> sub architectures). This is impossible to specify unless we introduce it in
> the buildroot configuration system (like several flavors of ARM). And this,
> in turn, seems too much to make just one package happy.

I might be wrong, but is it not the case that only one of the two
micro-architectures --- specifically, avr32b as used by the ap7 core
--- is relevant for Buildroot? (I'm not aware of a Linux port for the
avr32a architecture, as used by the uc3 core.)

If so, then it seems to me that it would be well worth calling the
compiler with the precise micro-architecture specified. This might be
expected to have a positive impact beyond just the openpgm package.

Simon.

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Thomas Petazzoni]

Dear Simon Dawson,

On Sat, 2 Nov 2013 08:03:51 +0000, Simon Dawson wrote:
> Hi Alexander.
> 
> On 1 November 2013 20:21, Alexander Lukichev
> <alexander.lukichev@gmail.com> wrote:
> > The compiler (that particular toolchain) has those intrinsic functions but
> > is able to generate them only if the exact CPU sub architecture is
> > specified, not just AVR32 (their implementations differ for each of the two
> > sub architectures). This is impossible to specify unless we introduce it in
> > the buildroot configuration system (like several flavors of ARM). And this,
> > in turn, seems too much to make just one package happy.
> 
> I might be wrong, but is it not the case that only one of the two
> micro-architectures --- specifically, avr32b as used by the ap7 core
> --- is relevant for Buildroot? (I'm not aware of a Linux port for the
> avr32a architecture, as used by the uc3 core.)
> 
> If so, then it seems to me that it would be well worth calling the
> compiler with the precise micro-architecture specified. This might be
> expected to have a positive impact beyond just the openpgm package.

I did a minimal test case, and even by specifying -march and -mpart,
sync_add_and_fetch_2 remains an undefined symbol. Interestingly, if you
use sync_add_and_fetch() on a pointer to a 4 bytes value, there's no
problem, but if it's a pointer to a 2 bytes value, then the intrinsics
uses sync_add_and_fetch_2, which doesn't work.

Test case with a pointer to a 4 bytes value
===========================================

$ cat toto.c 
int foo(void) {
	unsigned int *ptr;
	return __sync_add_and_fetch(ptr, 2);
}
$ avr32-linux-gcc -march=ap -mpart=ap7200 -fPIC -c toto.c 
$ avr32-linux-gcc -march=ap -mpart=ap7200 -fPIC -shared -Wl,-soname,libtoto.so.1 -o libtoto.so.1 toto.o 
$ avr32-linux-readelf -a libtoto.so.1 | grep sync_add
$

 => no problem

Test case with a pointer to a 2 bytes value
===========================================

$ cat toto.c 
int foo(void) {
	unsigned short *ptr;
	return __sync_add_and_fetch(ptr, 2);
}
$ avr32-linux-gcc -march=ap -mpart=ap7200 -fPIC -c toto.c 
$ avr32-linux-gcc -march=ap -mpart=ap7200 -fPIC -shared -Wl,-soname,libtoto.so.1 -o libtoto.so.1 toto.o 
$ avr32-linux-readelf -a libtoto.so.1 | grep sync_add
0000149c  00000b29 R_AVR32_GLOB_DAT  00000000   __sync_add_and_fetch_2 + 0
    11: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __sync_add_and_fetch_2
    43: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __sync_add_and_fetch_2
$

 => unresolved symbol

Any idea?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Simon Dawson]

Hi Thomas, Alexander.

On 2 November 2013 11:26, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I did a minimal test case, and even by specifying -march and -mpart,
> sync_add_and_fetch_2 remains an undefined symbol. Interestingly, if you
> use sync_add_and_fetch() on a pointer to a 4 bytes value, there's no
> problem, but if it's a pointer to a 2 bytes value, then the intrinsics
> uses sync_add_and_fetch_2, which doesn't work.

Interesting. Alexander: are we missing a trick here? How did you get
the compiler to use the correct intrinsics?

Simon.

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Alexander Lukichev]

Hi Simon, Thomas,

11/02/2013 06:51 PM, Simon Dawson wrote:
> Interesting. Alexander: are we missing a trick here? How did you get
> the compiler to use the correct intrinsics?

I do not remember. I'll take a look tomorrow on my faster laptop. It
may even be that I have mixed myself up then.

-- 
Best regards,
  Alexander Lukichev

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Alexander Lukichev]

Hi Simon, Thomas,

2013/11/2 Simon Dawson <spdawson@gmail.com>

> On 2 November 2013 11:26, Thomas Petazzoni wrote:
> > I did a minimal test case, and even by specifying -march and -mpart,
> > sync_add_and_fetch_2 remains an undefined symbol. Interestingly, if you
> > use sync_add_and_fetch() on a pointer to a 4 bytes value, there's no
> > problem, but if it's a pointer to a 2 bytes value, then the intrinsics
> > uses sync_add_and_fetch_2, which doesn't work.
>
> Interesting. Alexander: are we missing a trick here? How did you get
> the compiler to use the correct intrinsics?
>
>
No, you don't. I must have hallucinated the whole thing.

I have now tried to check with a locally built toolchain, and it also could
not
generate 2-byte versions of those functions, for all 3 -march= alternatives
(ap,
ucr1, ucr2; I remember that I used ucr2 previously). Nor could I find the
code
for them in GCC sources (I remember vaguely that I stumbled upon it during
my
initial attempts to pacify openpgm).

In addition, the document http://www.atmel.com/Images/doc32074.pdf on page 8
indeed claims to support 4-byte (int) versions of those functions, saying
nothing
about other data types.

I apologize both for the delay and for making other people wasting time on
this.

--
Best regards,
  Alexander Lukichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131106/18718b0e/attachment.html>

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Thomas Petazzoni]

Alexander, Simon,

On Wed, 6 Nov 2013 19:27:46 +0200, Alexander Lukichev wrote:
> Hi Simon, Thomas,

> In addition, the document http://www.atmel.com/Images/doc32074.pdf on page 8
> indeed claims to support 4-byte (int) versions of those functions, saying
> nothing
> about other data types.
> 
> I apologize both for the delay and for making other people wasting time on
> this.

Well, I believe your original patch remains almost good then: openpgm
cannot be built on avr32 because the AVR32 compiler doesn't provide the
required compiler intrinsics.

I think I would just turn the dependency from a !BR2_avr32 into
a !BR2_GCC_VERSION_4_2_2_AVR32_2_1_5, with a comment that explains that
it lacks some required intrinsics.

However, as Simon said, maybe it would anyway be useful to pass
-march=ap when building things, since that's the only AVR32 processor
variant that ever had Linux support. So something like the following
change would maybe be good to have. Simon, if you're interested in
picking this up, giving it a test and submitting it, it would be great!

diff --git a/arch/Config.in.avr32 b/arch/Config.in.avr32
index 199c150..8429589 100644
--- a/arch/Config.in.avr32
+++ b/arch/Config.in.avr32
@@ -3,3 +3,6 @@ config BR2_ARCH
 
 config BR2_ENDIAN
        default "BIG"
+
+config BR2_GCC_TARGET_ARCH
+       default "ap"


Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Alexander Lukichev]

Hi,

2013/11/6 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> Well, I believe your original patch remains almost good then: openpgm
> cannot be built on avr32 because the AVR32 compiler doesn't provide the
> required compiler intrinsics.
> <http://free-electrons.com>
>

Another option would be to build openpgm without fancy code that uses those
intrinsics. If I disable some constants defined in configure script when
intrinsics
are expected from the toolchain, the code does not use them but instead
tries to use pthread_spin_{lock,trylock,unlock}() functions. Curiously, my
toolchain,
built with "linuxthreads (stable/old)", does not have them. Should it? I
have
attached defconfig I use.

I have tried to rebuild the toolchain with "linuxthreads" but it complained
somewhere
in uClibc:

  CC libc/unistd/confstr.os
  CC libc/unistd/usleep.os
  CC libpthread/linuxthreads/forward.oS
  CC libpthread/linuxthreads/libc-cancellation.oS
  CC libpthread/linuxthreads/libc_pthread_init.oS
  CC libc/misc/elf/dl-iterate-phdr.oS
  CC libc/misc/internals/__uClibc_main.oS
  CC libc/inet/rpc/rpc_thread.oS
In file included from
./libpthread/linuxthreads/sysdeps/pthread/bits/libc-tsd.h:24,
                 from libc/inet/rpc/rpc_thread.c:16:
./include/tls.h:6:22: error: tls.h: No such file or directory
make[1]: *** [libc/inet/rpc/rpc_thread.oS] Error 1

Could I fix this somehow?

I will send a disabling patch, of course, but I was just interested why my
toolchain
does not have spinlock support (POSIX [1] does not say that this is
restricted to
some extension).

[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html

--
Best regards,
  Alexander Lukichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131106/62d5cf9b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pthreads_stable_avr32_defconfig
Type: application/octet-stream
Size: 7718 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131106/62d5cf9b/attachment-0001.obj>

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Thomas Petazzoni]

Dear Alexander Lukichev,

(Your e-mail wrapping is weird: it leaves one word alone on some lines.
Strange. Maybe some GMail craziness.)

On Wed, 6 Nov 2013 20:21:31 +0200, Alexander Lukichev wrote:

> Another option would be to build openpgm without fancy code that uses those
> intrinsics. If I disable some constants defined in configure script when
> intrinsics
> are expected from the toolchain, the code does not use them but instead
> tries to use pthread_spin_{lock,trylock,unlock}() functions. Curiously, my
> toolchain,
> built with "linuxthreads (stable/old)", does not have them. Should it? I
> have
> attached defconfig I use.

There is no implementation of pthread_spin_*() in the linuxthreads.old
thread implementation in uClibc. You should use NPTL instead when
available.

> I have tried to rebuild the toolchain with "linuxthreads" but it complained
> somewhere in uClibc:

Yes, I believe linuxthreads is known to be broken for a number of
architectures. From the Config.in help text in uClibc:

          The new version has not been tested much, and lacks ports for
          arches which glibc does not support (like bfin/frv/etc...),
          but is based on the latest code from glibc, so it may be the
          only choice for the newer ports (like alpha/amd64/64bit
          arches and hppa).

> ./libpthread/linuxthreads/sysdeps/pthread/bits/libc-tsd.h:24,
>                  from libc/inet/rpc/rpc_thread.c:16:
> ./include/tls.h:6:22: error: tls.h: No such file or directory
> make[1]: *** [libc/inet/rpc/rpc_thread.oS] Error 1
> 
> Could I fix this somehow?

I don't think fixing linuxthreads in uClibc is really worth it, to be
honest.

Moreover, Simon said that while uClibc 0.9.33 does build fine for
AVR32, it doesn't work properly on the target, and he is still using
uClibc 0.9.31 + a good stack of patches on top of it.

I think we should just disable OpenPGM on AVR32. If somebody ever cares
about this, he will be in charge of fixing it :)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/1] openpgm: disable on AVR32

[Simon Dawson]

On 6 November 2013 17:39, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> However, as Simon said, maybe it would anyway be useful to pass
> -march=ap when building things, since that's the only AVR32 processor
> variant that ever had Linux support. So something like the following
> change would maybe be good to have. Simon, if you're interested in
> picking this up, giving it a test and submitting it, it would be great!
>
> diff --git a/arch/Config.in.avr32 b/arch/Config.in.avr32
> index 199c150..8429589 100644
> --- a/arch/Config.in.avr32
> +++ b/arch/Config.in.avr32
> @@ -3,3 +3,6 @@ config BR2_ARCH
>
>  config BR2_ENDIAN
>         default "BIG"
> +
> +config BR2_GCC_TARGET_ARCH
> +       default "ap"

Okay; I think this is worth doing --- will submit a patch.

Simon.