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

[Arnout Vandecappelle]

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 at buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot