Re: ILP32 for ARM64: testing with glibc testsuite

[Yury Norov <ynorov@caviumnetworks.com>]

On Wed, Nov 16, 2016 at 03:25:40PM +0400, Maxim Kuvyrkov wrote:
> [Resending with trimmed CC: to avoid libc-alpha's spam filter]
> 
> > On Nov 9, 2016, at 1:56 PM, Yury Norov <ynorov@caviumnetworks.com> wrote:
> > 
> > On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote:
> >> Hi all,
> >> 
> >> [add libc-alpha mail list]
> >> 
> >> For libc-alpha: this is the part of LKML submission with latest
> >> patches for aarch64/ilp32.
> >> https://www.spinics.net/lists/arm-kernel/msg537846.html
> >> 
> >> Glibc that I use has also included consolidation patches from Adhemerval
> >> Zanella and me that are still not in the glibc master. The full series is:
> >> https://github.com/norov/glibc/tree/ilp32-2.24-dev2
> >> 
> >> Below is the results of glibc testsuite run for aarch64/lp64
> >> in different configurations. Column names meaning:
> >> kvgv: kernel is vanilla, glibc is vanilla;
> >> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config; 
> >>      glibc is vanilla;
> >> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla;
> >> kege: kernel patches are applied and enabled, glibc patches are applied.
> >> 
> >> Only different lines are shown. Full results are in attached archive. 
> 
> Hi Yury,
> 
> The general requirement merging ILP32 glibc patches is that LP64 does not regress in any reasonable configuration.  This means that there should be 0 regressions between kvgv and kvge -- i.e., glibc in LP64 mode with and without ILP32 patches does not regress on the vanilla kernel.  The kvge configuration is not in your testing matrix, and I suggest you make sure it has no regressions before fixing the more "advanced" configuration of kege.
> 
> Ideally, there should be no regressions between kvgv and kege configurations, but I don't consider this to a requirement for glibc acceptance of ILP32 patches, since any regressions between kvge and kege configurations are likely to be on the kernel side.
> 
> Speculating on the kernel requirements for ILP32 kernel patchset, I think there should be 0 regressions between kvgv and kdgv configurations, where you have only 3 tests to investigate and fix.
> 
> [I do appreciate that there are progressions in your results as well, but the glibc policy is that they do not offset regressions.]
> 
> The above only concerns LP64 support in kernel and glibc.
> 
> Regarding ILP32 runtime, my opinion is that it is acceptable for ILP32 to have extra failures compared to LP64, since these are not regressions, but, rather, failures of a new configuration.  From a superficial glance is seems that ILP32 linknamespace support requires attention, as well as stack unwinding (judging from NPTL failures).
> 
> 
> --
> Maxim Kuvyrkov
> www.linaro.org

Hi Maxim, others,

From last email we have fixed major part of fails, and also tested 
vanilla kernel with ilp32-enabled glibc, as Maxim asked (kvge column).

Source trees:
https://github.com/norov/glibc/tree/ilp32-2.24-dev5
https://github.com/norov/linux/tree/ilp32-4.9-rc4

Some fails analysis is below.
                                        ILP32   LP64    kvge    Vanilla
c++-types-check				FAIL	PASS	PASS	PASS
conform/ISO/stdio.h/linknamespace	FAIL	FAIL    FAIL    PASS
conform/ISO11/stdio.h/linknamespace	FAIL	FAIL    FAIL    PASS
conform/ISO99/stdio.h/linknamespace	FAIL	FAIL    FAIL    PASS
conform/POSIX/stdio.h/linknamespace	FAIL	FAIL    FAIL    PASS
conform/POSIX/sys/stat.h/linknamespace  FAIL	FAIL    FAIL    PASS
conform/UNIX98/stdio.h/linknamespace	FAIL	FAIL    FAIL    PASS
conform/XOPEN2K/stdio.h/linknamespace	FAIL	FAIL    FAIL    PASS
conform/XPG3/stdio.h/linknamespace	FAIL	FAIL    FAIL    PASS
conform/XPG4/stdio.h/linknamespace	FAIL	FAIL    FAIL    PASS
elf/check-localplt			FAIL	FAIL    FAIL    PASS
elf/tst-tls1				FAIL	PASS	PASS	PASS
elf/tst-tls1-static			FAIL	PASS	PASS	PASS
elf/tst-tls2				FAIL	PASS	PASS	PASS
elf/tst-tls2-static			FAIL	PASS	PASS	PASS
elf/tst-tls3				FAIL	PASS	PASS	PASS
iconvdata/mtrace-tst-loading		FAIL	FAIL	FAIL    PASS
iconvdata/tst-loading			FAIL	FAIL	FAIL    PASS
io/check-installed-headers-c		FAIL	FAIL	FAIL    PASS
io/check-installed-headers-cxx	        FAIL	FAIL	FAIL    PASS
localedata/mtrace-tst-leaks		PASS	FAIL	FAIL    PASS
localedata/tst-leaks			PASS	FAIL	FAIL    PASS
malloc/tst-malloc-backtrace		PASS	PASS	PASS    FAIL
malloc/tst-malloc-thread-exit		PASS	PASS	PASS    FAIL
malloc/tst-malloc-usable		PASS	PASS	PASS    FAIL
malloc/tst-mallocfork			PASS	PASS	PASS    FAIL
malloc/tst-mallocstate		        PASS	PASS	PASS    FAIL
malloc/tst-mallopt			PASS	PASS	PASS    FAIL
malloc/tst-mcheck			PASS	PASS	PASS    FAIL
malloc/tst-memalign			PASS	PASS	PASS    FAIL
malloc/tst-obstack			PASS	PASS	PASS    FAIL
malloc/tst-posix_memalign		PASS	PASS	PASS    FAIL
malloc/tst-pvalloc			PASS	PASS	PASS    FAIL
malloc/tst-realloc			PASS	PASS	PASS    FAIL
malloc/tst-scratch_buffer		PASS	PASS	PASS    FAIL
malloc/tst-trim1			PASS	PASS	PASS    FAIL
math/test-double			PASS	PASS	PASS    FAIL
math/test-double-finite		        PASS	PASS	PASS    FAIL
math/test-idouble			PASS	PASS	PASS    FAIL
misc/tst-writev				 NA	 NA 	 NA     PASS
posix/tst-getaddrinfo4			PASS	PASS    FAIL 	PASS
posix/tst-getaddrinfo5			PASS	PASS    FAIL	PASS
nptl/tst-cancel26                       FAIL    PASS    PASS    PASS        
nptl/tst-cancel27                       FAIL    PASS    PASS    PASS
posix/tst-regex2			FAIL	FAIL	FAIL	PASS
rt/tst-mqueue1				FAIL 	PASS    PASS    PASS
rt/tst-mqueue2				FAIL 	PASS    PASS    PASS
rt/tst-mqueue4				FAIL 	PASS    PASS    PASS
rt/tst-mqueue7				FAIL 	PASS    PASS    PASS
stdlib/tst-makecontext3			FAIL 	PASS    PASS    PASS
sunrpc/bug20790			        PASS	PASS	 NA 	 NA     
sysvipc/test-sysvmsg			PASS	PASS     NA      NA
sysvipc/test-sysvsem			PASS	PASS     NA      NA
sysvipc/test-sysvshm			PASS	PASS     NA      NA

Conform tests fail most probably because I have vanilla headers at 
standard paths (/usr/include). Modified headers are under different
testing location. Steve also tested it, and he has modified headers at
/usr/include, and he doesn't see failures of conform tests. I don't
think that kernel or wrong ABI caused this regression. Most probably
it's configuration issue. I also think that glibc should take headers
from testing directory, not from standard paths. For me it's dangerous
to replace standard headers with untested ones. Is there some option
in glibc testsuite configuration to provide path to headers explicitly?

elf/* tests fail only in ILP32 mode. We tracked it down to the linker
problem that replaces accesses to TLS with direct address calculation
if possible, and does it wrong for ilp32. This is definitely a linker
problem, and ABI and kernel are not involved here.

iconvdata/mtrace-tst-loading, iconvdata/tst-loading, io/check-installed-headers-c
and io/check-installed-headers-cxx are most probably failing due to installed
headers, like conform tests.

localedata/mtrace-tst-leaks and localedata/tst-leaks fail only for me.
Steve has it passed. I'm not sure but it also looks like
configuration issue, or similar.

posix/tst-getaddrinfo4 and posix/tst-getaddrinfo5 check broken URLs.
We should investigate it, but I don't think it's ABI issue. Also, if I
run them manually, they return 0, which means they are passed, I
suppose.

nptl/tst-cancel26, nptl/tst-cancel27, rt/tst-mqueue1,2,4,7 are also looking
like the TLS issue.

posix/tst-regex2 and stdlib/tst-makecontext3 fail only for me, so it's
probably my local problem.

So, with all regressions still been in the list, major part is
looking like my local configuration problems. Others fail due to
linker wrong behavior. I don't see any obvious failures caused
by kernel or ABI errors.

Yury.