Re: RISC-V test results

["Maciej W. Rozycki" <macro at wdc dot com>]

On Wed, 31 Jul 2019, Joseph Myers wrote:

> >  For some reason I haven't established yet lp64 results are significantly 
> > worse than lp64d ones, which in turn are similar to these previously 
> > obtained for 2.29.  I have noticed that out of 140 lp64 FAILs 90 are due 
> > to SIGABRT having been raised, including said nptl/tst-stack4.  I'm still 
> > investigating the cause, which is likely outside glibc as I can see there 
> > have been results posted now and they are fine for lp64.
> 
> To confirm: have you made sure that libgcc_s and libstdc++ shared 
> libraries for this ABI, from the compiler used for testing, are copied to 
> the glibc build directory (or present in the default dynamic linker search 
> path)?  Missing libgcc_s causes both many NPTL tests to fail and some to 
> hang.

 Good point!  I wasn't aware of this dependency on these libraries, so I 
have double-checked what was going on here.

 So what I have found out is as follows.  I actually have outstanding GCC 
patches applied (pending FSF making up their minds about my WDC copyright 
assignment) to get things automatically properly installed in the sysroot 
if requested; I've had too many cases of using a stale version of such 
libraries previously copied manually to be able to rely on such a 
misarrangement:

$ find sysroot -name 'libgcc_s*.so*' -o -name 'libstdc++*.so*' | sort
sysroot/usr/lib64/lp64/libgcc_s.so
sysroot/usr/lib64/lp64/libgcc_s.so.1
sysroot/usr/lib64/lp64/libstdc++.so
sysroot/usr/lib64/lp64/libstdc++.so.6
sysroot/usr/lib64/lp64/libstdc++.so.6.0.26
sysroot/usr/lib64/lp64/libstdc++.so.6.0.26-gdb.py
sysroot/usr/lib64/lp64d/libgcc_s.so
sysroot/usr/lib64/lp64d/libgcc_s.so.1
sysroot/usr/lib64/lp64d/libstdc++.so
sysroot/usr/lib64/lp64d/libstdc++.so.6
sysroot/usr/lib64/lp64d/libstdc++.so.6.0.26
sysroot/usr/lib64/lp64d/libstdc++.so.6.0.26-gdb.py
$ 

That makes sure that these shared GCC libraries are available to the host 
system along with any other shared libraries, however they are not 
automatically picked up by the dynamic loader or explicitly requested by 
the linker flags used by our test suite.

 What I have come up with is I have added:

'sysdep-LDFLAGS=-Wl,-rpath,$(shell $(CC) -print-file-name=libgcc_s.so | xargs realpath | xargs dirname)'

to the `make check' invocation so that the correct location of the shared 
`libgcc_s' library is automagically added according to the multilib used, 
avoiding the risk of a human error.  My choice of `sysdep-LDFLAGS' follows 
my observation that this `make' variable is only appended to rather than 
preassigned and it is included among the link flags used with test cases.  
I'm sharing this in a hope it may help someone; we may want to define and 
document a proper `make' variable to use instead for passing test flags 
like this one.

 I have run a subset of the lp64 tests of which some previously aborted 
and they passed this time, so I have started full testing and will have 
hopefully good results by tomorrow.

 In the course of `Makefile' examination I have noticed that we have no 
way to remove compiled tests only, that is `make tests-clean' only removes 
test results and `make mostlyclean' does remove compiled tests, however it 
also removes compiled library code.

 Many of our test case names start with `tst-', however not all do and
therefore manual removal is problematic, so I think it would be good to 
have an auxiliary clean target for compiled tests only in case they need 
to be rebuild with a different set of flags.  I'll have to wait until my 
copyright assignment has been sorted before I can propose such an update 
though.

 Thanks for the hint!

  Maciej