This is the mail archive of the
mailing list for the glibc project.
Re: [RFC 0/6] glibc port to ARC architecture
- From: Vineet Gupta <Vineet dot Gupta1 at synopsys dot com>
- To: Joseph Myers <joseph at codesourcery 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: Thu, 7 Dec 2017 16:31:36 -0800
- Subject: Re: [RFC 0/6] glibc port to ARC architecture
- Authentication-results: sourceware.org; auth=none
- Newsgroups: gmane.comp.lib.glibc.alpha, gmane.linux.kernel.arc
- References: <firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org>
On 11/27/2017 02:16 PM, Joseph Myers wrote:
On Mon, 27 Nov 2017, Vineet Gupta wrote:
Any new port should have support added to build-many-glibcs.py for all
ABIs supported by the port (e.g. both endiannesses, if you support both BE
and LE, and any other ABI variants).
build-many-glibcs.py works for ARC now - after the 2 backports to gcc 7.2
Works with clean compilation test results for the glibc testsuite?
I presume you just want to know 010-glibcs-arc-linux-gnu-check-*.txt after running
scripts/build-many-glibcs.py <path> glibcs arc-linux-gnu
Summary of test results:
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.
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.
You should make sure that produces clean test results for all the
compilation tests, for all those variants.
You should also include results for the full testsuite, including
execution tests (whether testing natively, or cross testing with
test-wrapper set to execute tests for a cross build), in the submission of
the port (and those should be as clean as possible).
ATM we have around 200 failures for upstream tools (likely due to libgcc
unwinder patch not yet merged upstream). And just for data point, with github
based gcc including the non-merged patches that number comes down to ~100.
Bunch of them are in math/doubler and some in backtrace/nptl. Will this be
considered a blocker. I'm almost ready for next round, rebased recently !
You should make sure you regenerate libm-test-ulps for your port (from
scratch, truncate the file and run make regen-ulps).
Thx, that indeed help with quite a few failures.
If you look at
you'll see some known architecture-independent issues that are generic for
certain cases (some cases of cross-testing, particular kernel versions,
etc.). Beyond anything listed there, I'd say you should have no more than
10-20 FAILs in a well-maintained port, preferably less than that. 100
FAILs indicates there's still some work to do before the port can be
considered to be in a good state.
The 100 were due to lack of c++ support, stale math ulps etc, default sa_restorer
generated code etc (which libgcc unwinder is choosy about). And then there were
some genuine fixes such as:
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
Do you think it would be considered review/merge worthy. I will continue to work
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.