On Thu, 7 Dec 2017, Vineet Gupta wrote: > 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. 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. > 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. 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 joseph at codesourcery.com
