Hi Rosen,
> From: Rosen Penev <ros...@gmail.com>
> Sent: Thursday, December 24, 2020 8:07 AM
> To: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Hauke Mehrtens <ha...@hauke-m.de>; openwrt-de...@openwrt.org
> <openwrt-de...@openwrt.org>; Evgeniy Didin <di...@synopsys.com>;
> arc-...@synopsys.com <arc-...@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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
