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
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.
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
> <https://sourceware.org/glibc/wiki/Release/2.26#Architecture-independent>
> 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:
csu/test-as-const-tcb-offsets
misc/tst-syscall-list
dlfcn/tststatic5
misc/tst-clone3
...
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.
-Vineet
