arc700 + glibc fails

[Rosen Penev]

On Wed, Dec 23, 2020 at 8:40 PM Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
>
> Hi Rosen, Hauke!
>
> > On Wed, Dec 23, 2020 at 6:54 AM Hauke Mehrtens <hauke at hauke-m.de> wrote:
> > >
> > > Hi,
> > >
> > > ARC was switched from uClibc to glibc here:
> > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=95f1002acab574c24ad78f4453f091bf5a6731c7
> > > uClibc support was removed from OpenWrt in the next commit.
> > >
> > > It looks like arc700 is not supported by glibc 2.32, only ARC HS38 is
> > > supported.
>
> Correct, upstream glibc v2.32 only supports ARCv2 as of today.
> I forgot about that fact during discussion about uClibc removal here
> https://github.com/openwrt/openwrt/pull/3673#issuecomment-747373099
> because we used to add support for ARCompact ISA (i.e. ARC700 cores)
> via off-the-tree-patch, see
> https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/commit/571c4c3df73bddbbb012b792a62f03e76b980ef3
> and note how simple it is fixing exactly the issue reported here.
Great. My current patch against glibc is:

--- a/sysdeps/arc/atomic-machine.h
+++ b/sysdeps/arc/atomic-machine.h
@@ -64,6 +64,10 @@ typedef uintmax_t uatomic_max_t;
   __atomic_val_bysize (__arch_compare_and_exchange_val, int,           \
                       mem, new, old, __ATOMIC_ACQUIRE)

+#ifdef __ARC700__
+#define atomic_full_barrier()  ({ asm volatile ("sync":::"memory"); })
+#else
 #define atomic_full_barrier()  ({ asm volatile ("dmb 3":::"memory"); })
+#endif

 #endif /* _ARC_BITS_ATOMIC_H */
--- a/sysdeps/unix/sysv/linux/arc/syscall.S
+++ b/sysdeps/unix/sysv/linux/arc/syscall.S
@@ -24,8 +24,13 @@ ENTRY (syscall)
        mov_s   r1, r2
        mov_s   r2, r3
        mov_s   r3, r4
+#ifdef __ARC700__
+       mov     r4, r5
+       mov     r5, r6
+#else
        mov_s   r4, r5
        mov_s   r5, r6
+#endif

        ARC_TRAP_INSN
        brhi    r0, -4096, L (call_syscall_err)
--- a/sysdeps/unix/sysv/linux/arc/sysdep.h
+++ b/sysdeps/unix/sysv/linux/arc/sysdep.h
@@ -128,7 +128,11 @@ L (call_syscall_err):
ASM_LINE_SEP    \
     mov    r8, __NR_##syscall_name     ASM_LINE_SEP    \
     ARC_TRAP_INSN                      ASM_LINE_SEP

+# ifdef __ARC700__
+# define ARC_TRAP_INSN trap0
+# else
 # define ARC_TRAP_INSN trap_s 0
+# endif

 #else  /* !__ASSEMBLER__ */

@@ -139,7 +143,11 @@ extern long int __syscall_error (long int);
 hidden_proto (__syscall_error)
 # endif

+# ifdef __ARC700__
+# define ARC_TRAP_INSN "trap0          \n\t"
+# else
 # define ARC_TRAP_INSN "trap_s 0       \n\t"
+#endif

 # undef INTERNAL_SYSCALL_NCS
 # define INTERNAL_SYSCALL_NCS(number, nr_args, args...)        \

Initial results look promising. I'll test compilation before submitting.
>
> > > On the arc770 target I am getting this compiler errors in the glibc:
> > > -----------------
> > > msort.c: Assembler messages:
> > > msort.c:201: Error: opcode 'dmb' not supported for target arc700
> > > -----------------
> > > http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/749
> > >
> > > After this one is fixed I get this one:
> > > -----------------
> > > ../sysdeps/unix/sysv/linux/arc/syscall.S: Assembler messages:
> > > ../sysdeps/unix/sysv/linux/arc/syscall.S:27: Error: register must be
> > > either r0-r3 or r12-r15 for instruction 'mov_s'
> > > ../sysdeps/unix/sysv/linux/arc/syscall.S:28: Error: register must be
> > > either r0-r3 or r12-r15 for instruction 'mov_s'
> > > ---------------------
> > >
> > > Does anyone plan to fix glibc with arc700 or should we just remove the
> > > arc770 target, the arhs38 target is compiling?
>
> So indeed what we may do here is either to retrofit ARC700 into existing glibc
> via aforementioned patch in OpenWrt or remove support of ARC700 at all.
>
> I'd suggest for a moment to stop building for ARC700 while this discussion
> is in progress and some people who's opinion I'd like to hear also are
> on the Christmas break.
ARC700 can be marked as BROKEN which means disabled by default.
>
> > I'll look into it. My vote is to remove support for ARC altogether as
> > it doesn't seem any hardware uses it except for some dev kits.
>
> Well that I'd prefer to not do. Even though in upstream OpenWrt indeed we
> only have 2 development boards which we support, there might be other users
> (and here I mean companies, not even individuals) which use or plan to use
> OpenWrt on their ARC-based SoCs/boards.
>
> The fact those boards are not exposed to wider audience and are not sold
> as affordable consumer Wi-Fi routers doesn't mean they don't exist.
Right. The OpenWrt project began to service WiFi routers. That's still
most of the userbase.
>
> Moreover with recent introduction of ARCv3 processors which include
> 64-bit cores we're planning to add their support in OpenWrt as well
> as soon as our toolchain matures a little bit so that we're confident
> majority of packages could be built with it normally.
That's great to hear.
>
> So if ARC doesn't add a lot of troubles for the community, let's keep it
> in the project.
Not having hardware is quite limiting. That is, we can compile
binaries but there's no way to test if anything compiled actually
runs. I don't think even QEMU supports ARC.

No musl support is also irksome. Nobody wants uClibc-ng in here and
only a few want glibc in here. If glibc goes, ARC will go with it.
>
> > > I think the archs38 target was not runtime tested with glibc, could
> > > someone with access to the hardware please check if it is still working
> > > with glibc in master. gdbserver also got ARC support please also check
> > > if this now works and we can remove the dependency on !arc.
>
> Right, there's a chance we haven't run glibc flavor of OpenWrt on ARC,
> previously focused on uClibc. But we'll do that now, thanks for the hint!
>
> -Alexey