arc700 + glibc fails

[Alexey Brodkin]

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.

> > 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