[1/2] package/glibc: add support for ARC700

From: Sergey Matyukevich <sergey.matyukevich@synopsys.com>

Even though ARC700 glibc port is very close to ARCv2 port, it is formally
another ABI that requires appropriate maintenance. That includes running
extensive glibc test-suite and fixing discovered issues and regressions.
That effort was considered impractical due to ARCompact ISA reaching EOL.
Besides ARC700 processors are usually found on very resource constrained
devices that tend to use uClibc if they run Linux.

On the other hand adding ARC700 glibc support still can be useful for
development and testing purposes. This commit adds two glibc patches
that enable ARC700 support.

Fixes https://gitlab.com/buildroot.org/buildroot/-/jobs/3259666747 and
the likes.

Signed-off-by: Sergey Matyukevich <sergey.matyukevich@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
---
 .../glibc/0003-ARC-Synopsys-ARC700-support.patch   | 208 +++++++++++++++++++++
 1 file changed, 208 insertions(+)
 create mode 100644 package/glibc/0003-ARC-Synopsys-ARC700-support.patch

On Wed, 16 Nov 2022 00:52:34 +0100
Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:

> From: Sergey Matyukevich <sergey.matyukevich@synopsys.com>
> 
> Even though ARC700 glibc port is very close to ARCv2 port, it is formally
> another ABI that requires appropriate maintenance. That includes running
> extensive glibc test-suite and fixing discovered issues and regressions.
> That effort was considered impractical due to ARCompact ISA reaching EOL.
> Besides ARC700 processors are usually found on very resource constrained
> devices that tend to use uClibc if they run Linux.
> 
> On the other hand adding ARC700 glibc support still can be useful for
> development and testing purposes. This commit adds two glibc patches
> that enable ARC700 support.

Hmm, this commit only adds one patch. Also, what is the upstream status
of this patch? In order to make sure we can easily update glibc, I'm
not too fan to have patches that are not upstream.

Thomas

Hi Thomas,

> > Even though ARC700 glibc port is very close to ARCv2 port, it is formally
> > another ABI that requires appropriate maintenance. That includes running
> > extensive glibc test-suite and fixing discovered issues and regressions.
> > That effort was considered impractical due to ARCompact ISA reaching EOL.
> > Besides ARC700 processors are usually found on very resource constrained
> > devices that tend to use uClibc if they run Linux.
> >
> > On the other hand adding ARC700 glibc support still can be useful for
> > development and testing purposes. This commit adds two glibc patches
> > that enable ARC700 support.
> 
> Hmm, this commit only adds one patch.

Correct, because that's all what's needed for ARC700 to be supported by glibc
as good as ARC HS processors are. Seriously, there're just a couple of
instructions which need to be changed (like use "trap0" instead of "trap_s 0")
and dynamic loader name is different ("/lib/ld-linux-arc700.so.2"). All the
rest is some configuration/infrastructural nonsense.

> Also, what is the upstream status of this patch?

As it is said in the patch itself, we decided to not officially maintain ARC700 
in glibc due to very strict rules in the upstream glibc community for supported
architectures and ABI's. But given minimal differences compared to ARCv2
(read "ARC HS") port, IMHO it's practical to have ARC700 support "downstream"
with a bit more relaxed requirements on maintenance activities... which doesn't
mean I'd like to throw stuff over the wall and never do anything about it.

> In order to make sure we can easily update glibc, I'm not too fan to have
> patches that are not upstream.

That's understood, but for many releases that change was equally applicable to
newer glibc versions (as we touch code which is rarely being modified) and even
now I re-based or refreshed this patch from 2.34 to 2.36 automatically with
only changes of hunk offsets (for the record, even before refresh, the patch
got applied to the current glibc in Buildroot only showing patch warnings
related to offsets).

That said, if you're not comfortable with the current maintenance status of
glibc for ARC700, we may drop it and limit ARC700 to only uClibc, otherwise
let's keep that patch until it seriously get in the way on glibc upgrade etc.

-Alexey

On 16/11/2022 16:33, Alexey Brodkin via buildroot wrote:
> Hi Thomas,
> 
>>> Even though ARC700 glibc port is very close to ARCv2 port, it is formally
>>> another ABI that requires appropriate maintenance. That includes running
>>> extensive glibc test-suite and fixing discovered issues and regressions.
>>> That effort was considered impractical due to ARCompact ISA reaching EOL.
>>> Besides ARC700 processors are usually found on very resource constrained
>>> devices that tend to use uClibc if they run Linux.

  This sounds very much like we should use uClibc in snps_arc700_axs101_defconfig.

>>>
>>> On the other hand adding ARC700 glibc support still can be useful for
>>> development and testing purposes. This commit adds two glibc patches

  "Development and testing purposes" is really not making a strong case... It 
sounds like the only reason to keep those glibc patches is to be able to test 
glibc, but you don't want to commit to really fully support glibc, so what is 
the point then?

>>> that enable ARC700 support.

  The cover letter says that it fixes something, then the commit message should 
contain a Fixes: line so it's clear that this patch is for master, not next.

>>
>> Hmm, this commit only adds one patch.
> 
> Correct, because that's all what's needed for ARC700 to be supported by glibc
> as good as ARC HS processors are. Seriously, there're just a couple of
> instructions which need to be changed (like use "trap0" instead of "trap_s 0")
> and dynamic loader name is different ("/lib/ld-linux-arc700.so.2"). All the
> rest is some configuration/infrastructural nonsense.
> 
>> Also, what is the upstream status of this patch?
> 
> As it is said in the patch itself, we decided to not officially maintain ARC700
> in glibc due to very strict rules in the upstream glibc community for supported
> architectures and ABI's. But given minimal differences compared to ARCv2
> (read "ARC HS") port, IMHO it's practical to have ARC700 support "downstream"
> with a bit more relaxed requirements on maintenance activities... which doesn't
> mean I'd like to throw stuff over the wall and never do anything about it.

  Yeah, what you're saying is: fully supporting it is a lot of effort because 
you have to run all the tests every time glibc is updated (and there are 
probably tests that will fail because they're somewhat fragile). While just 
carrying those patches is probably going to work for most people.

> 
>> In order to make sure we can easily update glibc, I'm not too fan to have
>> patches that are not upstream.
> 
> That's understood, but for many releases that change was equally applicable to
> newer glibc versions (as we touch code which is rarely being modified) and even
> now I re-based or refreshed this patch from 2.34 to 2.36 automatically with
> only changes of hunk offsets (for the record, even before refresh, the patch
> got applied to the current glibc in Buildroot only showing patch warnings
> related to offsets).
> 
> That said, if you're not comfortable with the current maintenance status of
> glibc for ARC700, we may drop it and limit ARC700 to only uClibc, otherwise
> let's keep that patch until it seriously get in the way on glibc upgrade etc.

  I don't see much advantage for Synopsys to spend any effort at all in 
maintaining glibc for ARC700. So I'd simply limit ARC700 to uClibc. If in the 
future you encounter a real use case for supporting glibc, then I think we can 
carry those glibc patches - as you said, they should still apply. But until 
then, I wouldn't bother.

  Regards,
  Arnout


> 
> -Alexey
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot