This is the mail archive of the
mailing list for the glibc project.
Re: [RFC 0/6] glibc port to ARC architecture
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Vineet Gupta <Vineet dot Gupta1 at synopsys dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, <Cupertino dot Miranda at synopsys dot com>, <linux-snps-arc at lists dot infradead dot org>, "libc-alpha @ sourceware . org" <libc-alpha at sourceware dot org>, Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>
- Date: Fri, 8 Dec 2017 11:15:27 +0000
- Subject: Re: [RFC 0/6] glibc port to ARC architecture
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org>
On Thu, 7 Dec 2017, Vineet Gupta wrote:
> I presume you just want to know 010-glibcs-arc-linux-gnu-check-*.txt after
> scripts/build-many-glibcs.py <path> glibcs arc-linux-gnu
> FAIL: elf/check-localplt
> Summary of test results:
> 1 FAIL
> 1169 PASS
> 15 XFAIL
> And even that failure is weird as
> (1) this is despite my updates to .../arc/localplt.data
> (2) My buildrooot based build reports this test to pass (after my update) but
> still fails in build-many-glibc based build.
The 011 log should show the output of all non-PASS tests, so allowing you
to identify the problem local PLT entry use (or if applicable, PLT entry
not used that was expected to be used). If it's e.g.
compiler-version-specific and hard to fix for some reason, note how
entries in localplt.data can use "?" to mark them optional (or can specify
an alternative relocation, in cases where a function is meant to be
interposable but may not have a PLT entry).
> Anyhow seems like this should be easy to figure - not mission critical as the
> system running testsuite xcheck is bootstrapped with same ld.so / libc etc.
For build-many-glibcs.py use to detect testsuite regressions for a
configuration, the baseline required is *no* failures in the parts of the
testsuite it runs. If there are any failures at all, that serves to hide
regressions (additional tests starting to fail, or the testsuite starting
to fail to build), because it just distinguishes zero / nonzero exit
status from "make check".
> We are now down to 51 (with github based gcc: more obviously with upstream
> gcc). I think only a very small percentage (~10% guess) would be due to
> missing glibc bits per-se.
> Do you think it would be considered review/merge worthy. I will continue to
I think a plausible state to be merge-ready would be no more than 20
architecture-specific failures, *with upstream GCC and binutils*. We've
had enough problems in the past with glibc ports that turn out to rely on
non-upstream toolchain pieces that I think you need results with upstream
tools essentially as good as those with non-upstream before inclusion of
the port is appropriate. So you should get whatever GCC fixes are needed
upstream sooner rather than later. (That means upstream in GCC mainline
so GCC 8 is ready for the port. Release branch backports are at your
discretion, although it's generally a good idea to make sure the GCC port
is in a good state in the most recent release branch, where there is any
GCC release branch supporting the architecture at all.)
That does not mean you should stop work on eliminating failures once down
to 20, as many ports are rather better than that, just that 20 is more
comparable with other reasonably well maintained glibc ports.
It's still be appropriate to submit the code for review now, before you're
down to 20 failures, given that a port is likely to need to go through
multiple rounds of review anyway before it's ready for inclusion in glibc.
Note that it should be possible for a new port to go into glibc during the
release freeze period (January), provided it's clear the changes cannot
affect other ports. So if you have any fixes to architecture-independent
parts of glibc that are needed for this port, you should submit them as
soon as possible, and separately from the main port submission.
> on bringing down failures. Otherwise new changes will mean I keep missing the
> sweeping arch updates / more failures ... I can post the full set of current
> failures if that helps steer decision.
The full list of failures, and whatever analysis you have of their causes
/ symptoms, should certainly be included in every submission of the port.
Joseph S. Myers