This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 0/6] glibc port to ARC architecture

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 for all
ABIs supported by the port (e.g. both endiannesses, if you support both BE
and LE, and any other ABI variants). 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/ <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/
(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 / 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 per-se.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]