glibc: ARC is now supported via patches

Given ARC port is just a very few patches away from upstream and if those are based on 2.29 everything works like a charm let's forget about SNPS GitHub stuff and use vanilla glibc plus patches.

This among other things solves a problem with stable fixes for glibc. Now when Buildroot switched to the tip of glibc's stable branch instead of applying cherry-picked patches ARC version would stay behind every time glibc's "version" gets updated in Buildroot.

But if we just apply ARC patches then we're good with whatever commit from upstream stable branch is taken.

---
 package/glibc/0001-longlong.h-sync-from-gcc.patch  |  133 +
 .../0002-ARC-add-definitions-to-elf-elf.h.patch    |   94 +
 package/glibc/0003-ARC-Initial-port-to-glibc.patch | 7625 ++++++++++++++++++++
 ...__start-as-entry-point-vs.-canonical-_sta.patch |  110 +
 ...eral-testsuite-failures-related-to-unwind.patch |  162 +
 package/glibc/0006-xxx-locla-chg.patch             |   31 +
 ...alloc_-set-get-_state-manually-to-abilist.patch |   26 +
 package/glibc/glibc.hash                           |    2 -
 package/glibc/glibc.mk                             |    7 -
 9 files changed, 8181 insertions(+), 9 deletions(-)
 create mode 100644 package/glibc/0001-longlong.h-sync-from-gcc.patch
 create mode 100644 package/glibc/0002-ARC-add-definitions-to-elf-elf.h.patch
 create mode 100644 package/glibc/0003-ARC-Initial-port-to-glibc.patch
 create mode 100644 package/glibc/0004-ARC-Enable-__start-as-entry-point-vs.-canonical-_sta.patch
 create mode 100644 package/glibc/0005-ARC-Fix-several-testsuite-failures-related-to-unwind.patch
 create mode 100644 package/glibc/0006-xxx-locla-chg.patch
 create mode 100644 package/glibc/0007-add-malloc_-set-get-_state-manually-to-abilist.patch

new file mode 100644
index 0000000..7f36322
@@ -0,0 +1,133 @@
+From db64fd4cc1712190db8459332731b5d8fe3e57b6 Mon Sep 17 00:00:00 2001
+From: Vineet Gupta <[email protected]>
+Date: Tue, 27 Jun 2017 20:28:04 +0300
+Subject: [PATCH 1/7] longlong.h: sync from gcc
+
+This corresponds to the version
+
+Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4>
+Date:   Tue Jun 27 16:10:15 2017 +0000
+
+        * longlong.h: Remove ns32k support.

q+
+ git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk at 249696 138bc75d-0d04-0410-961f-82ee72b054a4
+
+Signed-off-by: Alexey Brodkin <[email protected]>

+---
+ stdlib/longlong.h | 65 ++++++-------------------------------------------------

+ 1 file changed, 7 insertions(+), 58 deletions(-)
+
+diff --git a/stdlib/longlong.h b/stdlib/longlong.h
+index 0ec11c5..c24568a 100644
+--- a/stdlib/longlong.h
++++ b/stdlib/longlong.h
+@@ -197,17 +197,17 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype, UDItype, UDItype);
+ : "=r" ((USItype) (sh)), \
+ "=&r" ((USItype) (sl)) \
+ : "%r" ((USItype) (ah)), \

+-	     "rIJ" ((USItype) (bh)),					\
++	     "rICal" ((USItype) (bh)),					\
+ 	     "%r" ((USItype) (al)),					\
+-	     "rIJ" ((USItype) (bl)))
++	     "rICal" ((USItype) (bl)))

+ #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
+ __asm__ ("sub.f %1, %4, %5\n\tsbc %0, %2, %3" \
+ : "=r" ((USItype) (sh)), \
+ "=&r" ((USItype) (sl)) \
+ : "r" ((USItype) (ah)), \

+-	     "rIJ" ((USItype) (bh)),					\
++	     "rICal" ((USItype) (bh)),					\
+ 	     "r" ((USItype) (al)),					\
+-	     "rIJ" ((USItype) (bl)))
++	     "rICal" ((USItype) (bl)))

+
+ #define __umulsidi3(u,v) ((UDItype)(USItype)u*(USItype)v)
+ #ifdef __ARC_NORM__
+@@ -221,8 +221,8 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype, UDItype, UDItype);
+ } \
+ while (0)
+ #define COUNT_LEADING_ZEROS_0 32

+-#endif
+-#endif

++#endif /* __ARC_NORM__ */
++#endif /* __arc__ */
+
+ #if defined (__arm__) && (defined (__thumb2__) || !defined (__thumb__)) \
+ && W_TYPE_SIZE == 32
+@@ -858,42 +858,6 @@ extern UDItype __umulsidi3 (USItype, USItype);
+ #endif
+ #endif /* __mips__ */
+

+-#if defined (__ns32000__) && W_TYPE_SIZE == 32
+-#define umul_ppmm(w1, w0, u, v) \
+-  ({union {UDItype __ll;						\
+-	   struct {USItype __l, __h;} __i;				\
+-	  } __xx;							\
+-  __asm__ ("meid %2,%0"							\
+-	   : "=g" (__xx.__ll)						\
+-	   : "%0" ((USItype) (u)),					\
+-	     "g" ((USItype) (v)));					\
+-  (w1) = __xx.__i.__h; (w0) = __xx.__i.__l;})
+-#define __umulsidi3(u, v) \
+-  ({UDItype __w;							\
+-    __asm__ ("meid %2,%0"						\
+-	     : "=g" (__w)						\
+-	     : "%0" ((USItype) (u)),					\
+-	       "g" ((USItype) (v)));					\
+-    __w; })
+-#define udiv_qrnnd(q, r, n1, n0, d) \
+-  ({union {UDItype __ll;						\
+-	   struct {USItype __l, __h;} __i;				\
+-	  } __xx;							\
+-  __xx.__i.__h = (n1); __xx.__i.__l = (n0);				\
+-  __asm__ ("deid %2,%0"							\
+-	   : "=g" (__xx.__ll)						\
+-	   : "0" (__xx.__ll),						\
+-	     "g" ((USItype) (d)));					\
+-  (r) = __xx.__i.__l; (q) = __xx.__i.__h; })
+-#define count_trailing_zeros(count,x) \
+-  do {									\
+-    __asm__ ("ffsd     %2,%0"						\
+-	    : "=r" ((USItype) (count))					\
+-	    : "0" ((USItype) 0),					\
+-	      "r" ((USItype) (x)));					\
+-  } while (0)
+-#endif /* __ns32000__ */
+-

+ /* FIXME: We should test _IBMR2 here when we add assembly support for the
+ system vendor compilers.
+ FIXME: What's needed for gcc PowerPC VxWorks? __vxworks__ is not good
+@@ -1086,7 +1050,7 @@ extern UDItype __umulsidi3 (USItype, USItype);
+ } while (0)
+ #endif
+
+-#if defined(__sh__) && (!defined (__SHMEDIA__) || !__SHMEDIA__) && W_TYPE_SIZE == 32 ++#if defined(__sh__) && W_TYPE_SIZE == 32
+ #ifndef __sh1__
+ #define umul_ppmm(w1, w0, u, v) \
+ __asm__ ( \
+@@ -1159,21 +1123,6 @@ extern UDItype __umulsidi3 (USItype, USItype);
+
+ #endif /* __sh__ */
+

+-#if defined (__SH5__) && defined (__SHMEDIA__) && __SHMEDIA__ && W_TYPE_SIZE == 32
+-#define __umulsidi3(u,v) ((UDItype)(USItype)u*(USItype)v)
+-#define count_leading_zeros(count, x) \
+-  do									\
+-    {									\
+-      UDItype x_ = (USItype)(x);					\
+-      SItype c_;							\
+-									\
+-      __asm__ ("nsb %1, %0" : "=r" (c_) : "r" (x_));			\
+-      (count) = c_ - 31;						\
+-    }									\
+-  while (0)
+-#define COUNT_LEADING_ZEROS_0 32
+-#endif
+-

+ #if defined (__sparc__) && !defined (__arch64__) && !defined (__sparcv9) \
+ && W_TYPE_SIZE == 32
+ #define add_ssaaaa(sh, sl, ah, al, bh, bl) \
+--
+2.10.2
+

new file mode 100644
index 0000000..295dbe9

new file mode 100644
index 0000000..938bda4

index 5910dda..716e5d3 100644

index 5911dfe..6513364 100644

2.10.2

Part of the diff is not shown here. View the raw message.

Hello,

Any comments on this one?

Otherwise any chance to get it applied (not sure though if it gets applied now and then builds)?

-Alexey

Hello,

This is a bit too much feature patches IMO, it's a complete architecture port. I agree it's a backport from upstream, so it's not too bad. But since glibc 2.27, which includes this, is expected to be released on February 1st, I prefer to post-pone this change until glibc 2.27 gets released and we move to it.

Best regards,

Thomas

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

Hi Thomas,

That's very unfortunate but looks like we're not going to make ARC glibc port accepted before the upcoming release.

See https://sourceware.org/ml/libc-alpha/2017-12/msg00251.html for more details. Basically Vineet [who's doing the port] is now chasing a couple of issues found by glibc test-suite and before pretty much all of them are fixed the port will be considered for merging. That said having quite functional port in our fork we can and want to use it more to get better test coverage but for some more time [hopefully just before the next release] we'll need to use sources either from our GitHub [as we do today] or keep a set of patches.

Probably getting sources from GitHub is not the worst idea but my intention with patches on top of the tip of glibc sources from upstream "stable" branch was to get all latest fixes from this "stable" branch especially if those are fixes of build- and run-time issues.

-Alexey

Hello,

Gah, too bad :-/

I guess the easiest approach is to keep using your fork from Github. It's up to you to decide what is the glibc version you want to use in Buildroot, so if you want to move to something that is closer to what is being submitted to glibc upstream, then that's perfectly fine: we can take a patch changing the glibc package to use a new ARC glibc version from Github.

Is that OK for you ?

Best regards,

Thomas

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

Hi Thomas,

[snip]

Sure. Again I'm mostly concerned about things that will be fixed in glibc's "stable" branch but still affecting our fork. But I'm sure we'll be able to resolve it if it ever happens at all.

-Alexey

Hello,

You could always rebase your fork once in a while, or merge the glibc stable branch.

We are also not updating every day the glibc commit we're using for the glibc package, so we're also not getting fixes every day.

Best regards,

Thomas

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

FWIW, the blocker is need to use upstream components (gcc/binutils). So a glibc toolchain off of upstream gcc/binutils as well as upstream gcc 7.2 yields a working system, the glibc test suite built against has 100+ failures (mostly related to unwinding / cancelation) which is not acceptable to upstream glibc folks. So the issue is more in the tooling than the glibc pot per se.

-Vineet