| Message ID | 7bd9b9e9-e09c-56cb-acb1-f4f39378ebef@hauke-m.de |
|---|---|
| State | Superseded |
| Delegated to: | Hauke Mehrtens |
| Headers | show |
| Series | arc700 + glibc fails | expand |
On Wed, Dec 23, 2020 at 6:54 AM Hauke Mehrtens <hauke@hauke-m.de> wrote: > > Hi, > > ARC was switched from uClibc to glibc here: > https://git.openwrt.org/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. > > 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? 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. > > 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. > > Hauke > > > This fixes the first build problem: > ------------------------ > --- a/sysdeps/arc/atomic-machine.h > +++ b/sysdeps/arc/atomic-machine.h > @@ -64,6 +64,10 @@ > __atomic_val_bysize (__arch_compare_and_exchange_val, int, \ > mem, new, old, __ATOMIC_ACQUIRE) > > +#ifdef __ARCHS__ > #define atomic_full_barrier() ({ asm volatile ("dmb 3":::"memory"); }) > +#else > +#define atomic_full_barrier() ({ asm volatile ("sync":::"memory"); }) uClibc-ng uses __asm__ __volatile__("": : :"memory"). No idea if bug or not. > +#endif > > #endif /* _ARC_BITS_ATOMIC_H */ > ------------------------ > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi Rosen, Hauke! > On Wed, Dec 23, 2020 at 6:54 AM Hauke Mehrtens <hauke@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. > > 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. > 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. 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. So if ARC doesn't add a lot of troubles for the community, let's keep it in the project. > > 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
On Wed, Dec 23, 2020 at 8:40 PM Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > > Hi Rosen, Hauke! > > > On Wed, Dec 23, 2020 at 6:54 AM Hauke Mehrtens <hauke@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
Hi Rosen, > From: Rosen Penev <rosenp@gmail.com> > Sent: Thursday, December 24, 2020 8:07 AM > To: Alexey Brodkin <abrodkin@synopsys.com> > Cc: Hauke Mehrtens <hauke@hauke-m.de>; openwrt-devel@openwrt.org <openwrt-devel@openwrt.org>; Evgeniy Didin <didin@synopsys.com>; arc-gnu@synopsys.com <arc-gnu@synopsys.com> > Subject: Re: arc700 + glibc fails [snip] > --- 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. LGTM, though it's funny we seem to have this hunk already in upstream: ----------------------------->8----------------------------- /* Return nonzero iff ELF header is compatible with the running host. */ static inline int elf_machine_matches_host (const Elf32_Ehdr *ehdr) { return (ehdr->e_machine == EM_ARCV2 /* ARC HS. */ || ehdr->e_machine == EM_ARC_COMPACT); /* ARC 700. */ } ----------------------------->8----------------------------- [snip] > > 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. What does that mean in a sense of support? I.e. it won't be built in OpenWrt infrastructure as well as no binaries, nor packages will be built for the next releases of OpenWrt? If so I guess it might be OK, though read-on... > > 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. My colleagues are busy upstreaming QEMU port for ARCv2, see https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg11115.html. Review is in progress now and once everybody is happy it will be merged (I guess after a couple of re-spins as it usually happens). But the port itself is pretty stable and known to work well with both the Linux as well as Zephyr RTOS (where it's even a part of their SDK, see https://github.com/zephyrproject-rtos/sdk-ng/releases). So if of any interest you may play with it: * Sources are here: https://github.com/foss-for-synopsys-dwc-arc-processors/qemu * Build instructions are here: https://github.com/foss-for-synopsys-dwc-arc-processors/qemu/wiki/Building-QEMU-for-ARC I haven't tried to run images built with OpenWrt but what gets built with Buildroot works nice. So if it makes any sense I may try with OpenWrt and provide detailed instructions on how to get QEMU for ARC up and running. > 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. Ok, good. We don't have any plans for musl support as of today, but glibc will be supported surely, moreover we plan to submit all our work right to the upstream project as we do with all the other open source components. -Alexey
--- a/sysdeps/arc/atomic-machine.h +++ b/sysdeps/arc/atomic-machine.h @@ -64,6 +64,10 @@ __atomic_val_bysize (__arch_compare_and_exchange_val, int, \ mem, new, old, __ATOMIC_ACQUIRE) +#ifdef __ARCHS__ #define atomic_full_barrier() ({ asm volatile ("dmb 3":::"memory"); }) +#else +#define atomic_full_barrier() ({ asm volatile ("sync":::"memory"); }) +#endif #endif /* _ARC_BITS_ATOMIC_H */