Re: ILP32 for ARM64: testing with glibc testsuite

Re: ILP32 for ARM64: testing with glibc testsuite

[Yury Norov]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

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. 

I didn't analyze regressions deep yet, so any ideas/suggestions are appreciated.

Yury.

Test					kvgv	kdgv	kegv	kege
conform/ISO/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL
conform/ISO11/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL
conform/ISO99/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL
conform/POSIX/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL
conform/POSIX/sys/stat.h/linknamespace	PASS 	PASS 	PASS	FAIL
conform/UNIX98/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL
conform/XOPEN2K/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL
conform/XPG3/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL
conform/XPG4/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL
csu/tst-atomic				PASS 	PASS 	PASS	FAIL
elf/check-localplt			PASS 	PASS 	PASS	FAIL
iconvdata/mtrace-tst-loading		PASS	FAIL	PASS 	PASS
iconvdata/tst-loading			PASS	FAIL	PASS 	PASS
io/check-installed-headers-c		PASS 	PASS 	PASS	FAIL
io/check-installed-headers-cxx		PASS 	PASS 	PASS	FAIL
malloc/tst-malloc-backtrace		FAIL	PASS	PASS	PASS
malloc/tst-malloc-thread-exit		FAIL	PASS	PASS	PASS
malloc/tst-malloc-usable		FAIL	PASS	PASS	PASS
malloc/tst-mallocfork			FAIL	PASS	PASS	PASS
malloc/tst-mallocstate			FAIL	PASS	PASS	PASS
malloc/tst-mallopt			FAIL	PASS	PASS	PASS
malloc/tst-mcheck			FAIL	PASS	PASS	PASS
malloc/tst-memalign			FAIL	PASS	PASS	PASS
malloc/tst-obstack			FAIL	PASS	PASS	PASS
malloc/tst-posix_memalign		FAIL	PASS	PASS	PASS
malloc/tst-pvalloc			FAIL	PASS	PASS	PASS
malloc/tst-realloc			FAIL	PASS	PASS	PASS
malloc/tst-scratch_buffer		FAIL	PASS	PASS	PASS
malloc/tst-trim1			FAIL	PASS	PASS	PASS
nptl/tst-eintr4				PASS 	PASS 	PASS	NA
posix/tst-regex2			PASS	FAIL	FAIL	FAIL
posix/tst-getaddrinfo4			PASS	PASS	FAIL	FAIL
posix/tst-getaddrinfo5			PASS	PASS	FAIL	FAIL
sysvipc/test-sysvmsg			NA	NA	NA	FAIL
sysvipc/test-sysvsem			NA	NA	NA	FAIL
sysvipc/test-sysvshm			NA	NA	NA	FAIL

[-- Attachment #2: lp64.sum.tar.gz --]
[-- Type: application/gzip, Size: 37007 bytes --]

Re: ILP32 for ARM64: testing with glibc testsuite

[Yury Norov]

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. 
 
The same, plus ILP32 regressions:

Test					kvgv	kdgv	kegv	kege	ilp32
conform/ISO/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
conform/ISO11/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
conform/ISO99/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
conform/POSIX/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
conform/POSIX/sys/stat.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
conform/UNIX98/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
conform/XOPEN2K/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
conform/XPG3/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
conform/XPG4/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
csu/tst-atomic				PASS 	PASS 	PASS	FAIL	PASS
elf/check-localplt			PASS 	PASS 	PASS	FAIL	FAIL
iconvdata/mtrace-tst-loading		PASS	FAIL	PASS 	PASS	FAIL
iconvdata/tst-loading			PASS	FAIL	PASS 	PASS	PASS
io/check-installed-headers-c		PASS 	PASS 	PASS	FAIL	FAIL
io/check-installed-headers-cxx		PASS 	PASS 	PASS	FAIL	FAIL
malloc/tst-malloc-backtrace		FAIL	PASS	PASS	PASS	PASS
malloc/tst-malloc-thread-exit		FAIL	PASS	PASS	PASS	PASS
malloc/tst-malloc-usable		FAIL	PASS	PASS	PASS	PASS
malloc/tst-mallocfork			FAIL	PASS	PASS	PASS	PASS
malloc/tst-mallocstate			FAIL	PASS	PASS	PASS	PASS
malloc/tst-mallopt			FAIL	PASS	PASS	PASS	PASS
malloc/tst-mcheck			FAIL	PASS	PASS	PASS	PASS
malloc/tst-memalign			FAIL	PASS	PASS	PASS	PASS
malloc/tst-obstack			FAIL	PASS	PASS	PASS	PASS
malloc/tst-posix_memalign		FAIL	PASS	PASS	PASS	PASS
malloc/tst-pvalloc			FAIL	PASS	PASS	PASS	PASS
malloc/tst-realloc			FAIL	PASS	PASS	PASS	PASS
malloc/tst-scratch_buffer		FAIL	PASS	PASS	PASS	PASS
malloc/tst-trim1			FAIL	PASS	PASS	PASS	PASS
nptl/tst-eintr4				PASS 	PASS 	PASS	NA	NA
posix/tst-regex2			PASS	FAIL	FAIL	FAIL	FAIL
posix/tst-getaddrinfo4			PASS	PASS	FAIL	FAIL	PASS
posix/tst-getaddrinfo5			PASS	PASS	FAIL	FAIL	PASS
sysvipc/test-sysvmsg			NA	NA	NA	FAIL	PASS
sysvipc/test-sysvsem			NA	NA	NA	FAIL	PASS
sysvipc/test-sysvshm			NA	NA	NA	FAIL	PASS

c++-types-check				PASS	PASS	PASS	PASS	FAIL
debug/tst-backtrace4			PASS	PASS	PASS	PASS	FAIL
elf/check-abi-libc			PASS	PASS	PASS	PASS	FAIL
elf/tst-tls1				PASS	PASS	PASS	PASS	FAIL
elf/tst-tls1-static			PASS	PASS	PASS	PASS	FAIL
elf/tst-tls2				PASS	PASS	PASS	PASS	FAIL
elf/tst-tls2-static			PASS	PASS	PASS	PASS	FAIL
elf/tst-tls3				PASS	PASS	PASS	PASS	FAIL
math/check-abi-libm			PASS	PASS	PASS	PASS	FAIL
misc/tst-writev				PASS	PASS	PASS	PASS   	NA  
nptl/tst-cancel-self-canceltype		PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel1			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel10			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel11			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel13			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel15			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel16			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel17			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel18			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel2			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel20			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel21			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel24			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel25			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel26			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel27			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel3			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel4			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel5			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel6			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancel7			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx10			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx11			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx13			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx15			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx16			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx17			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx18			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx2			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx20			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx21			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx3			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx4			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx5			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx6			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cancelx7			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cleanup4			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cleanupx4			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cond-except			PASS	PASS	PASS	PASS	FAIL
nptl/tst-cond7				PASS	PASS	PASS	PASS	FAIL
nptl/tst-cond8				PASS	PASS	PASS	PASS	FAIL
nptl/tst-fini1				PASS	PASS	PASS	PASS	FAIL
nptl/tst-initializers1			PASS	PASS	PASS	PASS	FAIL
nptl/tst-initializers1-c11		PASS	PASS	PASS	PASS	FAIL
nptl/tst-initializers1-c89		PASS	PASS	PASS	PASS	FAIL
nptl/tst-initializers1-c99		PASS	PASS	PASS	PASS	FAIL
nptl/tst-initializers1-gnu11		PASS	PASS	PASS	PASS	FAIL
nptl/tst-initializers1-gnu89		PASS	PASS	PASS	PASS	FAIL
nptl/tst-initializers1-gnu99		PASS	PASS	PASS	PASS	FAIL
nptl/tst-join5				PASS	PASS	PASS	PASS	FAIL
nptl/tst-key3				PASS	PASS	PASS	PASS	FAIL
nptl/tst-mutex8				PASS	PASS	PASS	PASS	FAIL
nptl/tst-mutexpi8			PASS	PASS	PASS	PASS	FAIL
nptl/tst-once3				PASS	PASS	PASS	PASS	FAIL
nptl/tst-once4				PASS	PASS	PASS	PASS	FAIL
nptl/tst-oncex3				PASS	PASS	PASS	PASS	FAIL
nptl/tst-oncex4				PASS	PASS	PASS	PASS	FAIL
nptl/tst-rwlock15			PASS	PASS	PASS	PASS	FAIL
nptl/tst-rwlock8			PASS	PASS	PASS	PASS	FAIL
nptl/tst-rwlock9			PASS	PASS	PASS	PASS	FAIL
nptl/tst-sem11				PASS	PASS	PASS	PASS	FAIL
nptl/tst-sem12				PASS	PASS	PASS	PASS	FAIL
posix/bug-regex24			PASS	PASS	PASS	PASS	FAIL
rt/tst-mqueue1				PASS	PASS	PASS	PASS	FAIL
rt/tst-mqueue2				PASS	PASS	PASS	PASS	FAIL
rt/tst-mqueue4				PASS	PASS	PASS	PASS	FAIL
rt/tst-mqueue7				PASS	PASS	PASS	PASS	FAIL
rt/tst-mqueue8				PASS	PASS	PASS	PASS	FAIL
rt/tst-mqueue8x				PASS	PASS	PASS	PASS	FAIL
stdlib/tst-makecontext3			PASS	PASS	PASS	PASS	FAIL

Re: ILP32 for ARM64: testing with glibc testsuite

[Maxim Kuvyrkov]

[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



> 
> The same, plus ILP32 regressions:
> 
> Test					kvgv	kdgv	kegv	kege	ilp32
> conform/ISO/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
> conform/ISO11/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
> conform/ISO99/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
> conform/POSIX/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
> conform/POSIX/sys/stat.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
> conform/UNIX98/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
> conform/XOPEN2K/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
> conform/XPG3/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
> conform/XPG4/stdio.h/linknamespace	PASS 	PASS 	PASS	FAIL	FAIL
> csu/tst-atomic				PASS 	PASS 	PASS	FAIL	PASS
> elf/check-localplt			PASS 	PASS 	PASS	FAIL	FAIL
> iconvdata/mtrace-tst-loading		PASS	FAIL	PASS 	PASS	FAIL
> iconvdata/tst-loading			PASS	FAIL	PASS 	PASS	PASS
> io/check-installed-headers-c		PASS 	PASS 	PASS	FAIL	FAIL
> io/check-installed-headers-cxx		PASS 	PASS 	PASS	FAIL	FAIL
> malloc/tst-malloc-backtrace		FAIL	PASS	PASS	PASS	PASS
> malloc/tst-malloc-thread-exit		FAIL	PASS	PASS	PASS	PASS
> malloc/tst-malloc-usable		FAIL	PASS	PASS	PASS	PASS
> malloc/tst-mallocfork			FAIL	PASS	PASS	PASS	PASS
> malloc/tst-mallocstate			FAIL	PASS	PASS	PASS	PASS
> malloc/tst-mallopt			FAIL	PASS	PASS	PASS	PASS
> malloc/tst-mcheck			FAIL	PASS	PASS	PASS	PASS
> malloc/tst-memalign			FAIL	PASS	PASS	PASS	PASS
> malloc/tst-obstack			FAIL	PASS	PASS	PASS	PASS
> malloc/tst-posix_memalign		FAIL	PASS	PASS	PASS	PASS
> malloc/tst-pvalloc			FAIL	PASS	PASS	PASS	PASS
> malloc/tst-realloc			FAIL	PASS	PASS	PASS	PASS
> malloc/tst-scratch_buffer		FAIL	PASS	PASS	PASS	PASS
> malloc/tst-trim1			FAIL	PASS	PASS	PASS	PASS
> nptl/tst-eintr4				PASS 	PASS 	PASS	NA	NA
> posix/tst-regex2			PASS	FAIL	FAIL	FAIL	FAIL
> posix/tst-getaddrinfo4			PASS	PASS	FAIL	FAIL	PASS
> posix/tst-getaddrinfo5			PASS	PASS	FAIL	FAIL	PASS
> sysvipc/test-sysvmsg			NA	NA	NA	FAIL	PASS
> sysvipc/test-sysvsem			NA	NA	NA	FAIL	PASS
> sysvipc/test-sysvshm			NA	NA	NA	FAIL	PASS
> 
> c++-types-check				PASS	PASS	PASS	PASS	FAIL
> debug/tst-backtrace4			PASS	PASS	PASS	PASS	FAIL
> elf/check-abi-libc			PASS	PASS	PASS	PASS	FAIL
> elf/tst-tls1				PASS	PASS	PASS	PASS	FAIL
> elf/tst-tls1-static			PASS	PASS	PASS	PASS	FAIL
> elf/tst-tls2				PASS	PASS	PASS	PASS	FAIL
> elf/tst-tls2-static			PASS	PASS	PASS	PASS	FAIL
> elf/tst-tls3				PASS	PASS	PASS	PASS	FAIL
> math/check-abi-libm			PASS	PASS	PASS	PASS	FAIL
> misc/tst-writev				PASS	PASS	PASS	PASS   	NA  
> nptl/tst-cancel-self-canceltype		PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel1			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel10			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel11			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel13			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel15			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel16			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel17			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel18			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel2			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel20			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel21			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel24			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel25			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel26			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel27			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel3			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel4			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel5			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel6			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancel7			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx10			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx11			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx13			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx15			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx16			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx17			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx18			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx2			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx20			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx21			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx3			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx4			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx5			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx6			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cancelx7			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cleanup4			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cleanupx4			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cond-except			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cond7				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-cond8				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-fini1				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-initializers1			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-initializers1-c11		PASS	PASS	PASS	PASS	FAIL
> nptl/tst-initializers1-c89		PASS	PASS	PASS	PASS	FAIL
> nptl/tst-initializers1-c99		PASS	PASS	PASS	PASS	FAIL
> nptl/tst-initializers1-gnu11		PASS	PASS	PASS	PASS	FAIL
> nptl/tst-initializers1-gnu89		PASS	PASS	PASS	PASS	FAIL
> nptl/tst-initializers1-gnu99		PASS	PASS	PASS	PASS	FAIL
> nptl/tst-join5				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-key3				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-mutex8				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-mutexpi8			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-once3				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-once4				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-oncex3				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-oncex4				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-rwlock15			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-rwlock8			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-rwlock9			PASS	PASS	PASS	PASS	FAIL
> nptl/tst-sem11				PASS	PASS	PASS	PASS	FAIL
> nptl/tst-sem12				PASS	PASS	PASS	PASS	FAIL
> posix/bug-regex24			PASS	PASS	PASS	PASS	FAIL
> rt/tst-mqueue1				PASS	PASS	PASS	PASS	FAIL
> rt/tst-mqueue2				PASS	PASS	PASS	PASS	FAIL
> rt/tst-mqueue4				PASS	PASS	PASS	PASS	FAIL
> rt/tst-mqueue7				PASS	PASS	PASS	PASS	FAIL
> rt/tst-mqueue8				PASS	PASS	PASS	PASS	FAIL
> rt/tst-mqueue8x				PASS	PASS	PASS	PASS	FAIL
> stdlib/tst-makecontext3			PASS	PASS	PASS	PASS	FAIL

Re: ILP32 for ARM64: testing with glibc testsuite

[Yury Norov]

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,

Hi Maxim, thank you for response.

> 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.

Yes, I missed kvge as it's not so interesting from kernel point of
view. But it's needed for glibc. I'll run that test and report soon.

> 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).

Thanks again, it's clear, and I agree with your approach. Since
there's less than 6 weeks till freeze, we'll focus on lp64
regressions, and after that on ilp32-specific ones.

Yury.

Re: ILP32 for ARM64: testing with glibc testsuite

[Yury Norov]

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.

Re: ILP32 for ARM64: testing with glibc testsuite

[Florian Weimer]

On 11/24/2016 06:15 AM, Yury Norov wrote:

> 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?

There is something peculiar with your test setup, I think.  The conform 
tests do not do that for me.  How do you configure, build, and test glibc?

The instability in the malloc tests need investigation as well.  If you 
run this on a simulator, you need to increase the test timeout.

> 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.

The elf/check-localplt failure may have a different cause.  What does 
the test report in the .out file?

Thanks,
Florian

Re: ILP32 for ARM64: testing with glibc testsuite

[Yury Norov]

On Thu, Nov 24, 2016 at 08:36:16AM +0100, Florian Weimer wrote:
> On 11/24/2016 06:15 AM, Yury Norov wrote:
> 
> >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?
> 
> There is something peculiar with your test setup, I think.  The conform
> tests do not do that for me.  How do you configure, build, and test glibc?

This is my makefile to build it.
https://github.com/norov/build-glibc

If you have thoughts how to make it work right, I'll be really
appreciated.

> The instability in the malloc tests need investigation as well.  If you run
> this on a simulator, you need to increase the test timeout.

I run it on qemu. It doesn't look like instability. malloc tests
always fail on vanilla glibc, and always pass on patched one, for me.
Andrew has it passed for vanilla glibc as well.

> >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.
> 
> The elf/check-localplt failure may have a different cause.  What does the
> test report in the .out file?

yury@yury-N73SV:~/work/glibc-img/lp64.build$ cat ./elf/check-localplt.out
Extra PLT reference: libc.so: renameat

Seems yes, it doesn't look like a TLS problem. I'll check it.

Yury.

Re: ILP32 for ARM64: testing with glibc testsuite

[Florian Weimer]

On 11/24/2016 09:59 AM, Yury Norov wrote:
> On Thu, Nov 24, 2016 at 08:36:16AM +0100, Florian Weimer wrote:
>> On 11/24/2016 06:15 AM, Yury Norov wrote:
>>
>>> 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?
>>
>> There is something peculiar with your test setup, I think.  The conform
>> tests do not do that for me.  How do you configure, build, and test glibc?
>
> This is my makefile to build it.
> https://github.com/norov/build-glibc
>
> If you have thoughts how to make it work right, I'll be really
> appreciated.

Are you cross-compiling?  I did not expect that.  I thought native 
development was possible on aarch64 now.

>> The instability in the malloc tests need investigation as well.  If you run
>> this on a simulator, you need to increase the test timeout.
>
> I run it on qemu. It doesn't look like instability. malloc tests
> always fail on vanilla glibc, and always pass on patched one, for me.

Have you tried to increase test timeout?

> Andrew has it passed for vanilla glibc as well.

Does Andrew use QEMU as well?

>>> 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.
>>
>> The elf/check-localplt failure may have a different cause.  What does the
>> test report in the .out file?
>
> yury@yury-N73SV:~/work/glibc-img/lp64.build$ cat ./elf/check-localplt.out
> Extra PLT reference: libc.so: renameat
>
> Seems yes, it doesn't look like a TLS problem. I'll check it.

Thanks.

Florian

Re: ILP32 for ARM64: testing with glibc testsuite

[Andrew Pinski]

On Thu, Nov 24, 2016 at 1:06 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 11/24/2016 09:59 AM, Yury Norov wrote:
>>
>> On Thu, Nov 24, 2016 at 08:36:16AM +0100, Florian Weimer wrote:
>>>
>>> On 11/24/2016 06:15 AM, Yury Norov wrote:
>>>
>>>> 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?
>>>
>>>
>>> There is something peculiar with your test setup, I think.  The conform
>>> tests do not do that for me.  How do you configure, build, and test
>>> glibc?
>>
>>
>> This is my makefile to build it.
>> https://github.com/norov/build-glibc
>>
>> If you have thoughts how to make it work right, I'll be really
>> appreciated.
>
>
> Are you cross-compiling?  I did not expect that.  I thought native
> development was possible on aarch64 now.
>
>>> The instability in the malloc tests need investigation as well.  If you
>>> run
>>> this on a simulator, you need to increase the test timeout.
>>
>>
>> I run it on qemu. It doesn't look like instability. malloc tests
>> always fail on vanilla glibc, and always pass on patched one, for me.
>
>
> Have you tried to increase test timeout?
>
>> Andrew has it passed for vanilla glibc as well.
>
>
> Does Andrew use QEMU as well?

Mine was native on a ThunderX T88 machine with a vanilla linux  4.8rc3.

Thanks,
Andrew

>
>>>> 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.
>>>
>>>
>>> The elf/check-localplt failure may have a different cause.  What does the
>>> test report in the .out file?
>>
>>
>> yury@yury-N73SV:~/work/glibc-img/lp64.build$ cat ./elf/check-localplt.out
>> Extra PLT reference: libc.so: renameat
>>
>> Seems yes, it doesn't look like a TLS problem. I'll check it.
>
>
> Thanks.
>
> Florian
>

Re: ILP32 for ARM64: testing with glibc testsuite

[Ramana Radhakrishnan]

Yury,

>
> 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.

That's entirely possible. Is there a bug report in binutils about this
? Are you (or anyone else you know) looking at fixing the linker ?

regards
Ramana

Re: ILP32 for ARM64: testing with glibc testsuite

[Yury Norov]

On Fri, Nov 25, 2016 at 02:25:47PM +0000, Ramana Radhakrishnan wrote:
> Yury,
> 
> >
> > 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.
> 
> That's entirely possible. Is there a bug report in binutils about this
> ? Are you (or anyone else you know) looking at fixing the linker ?

This is detailed bug report in bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=20868

Yury

Re: ILP32 for ARM64: testing with glibc testsuite

[Zhangjian (Bamvor)]

Hi, Steve

On 2016/11/18 5:45, Steve Ellcey wrote:
> On Wed, 2016-11-16 at 15:22 +0400, Maxim Kuvyrkov wrote:
>>>
>>> On Nov 9, 2016, at 1:56 PM, Yury Norov <ynorov@caviumnetworks.com>
>>> wrote:
>>>
>>>>
>>>> Below is the results of glibc testsuite run for aarch64/lp64
>
> I have been running the glibc testsuite as well.  I have only run it on
> an ILP32 enabled kernel.  Using that kernel, top-of-tree glibc, and the
> ILP32 glibc patches I have no LP64 regressions.  There are 5 failures
> in LP64 mode but I get them with vanilla top-of-tree glibc sources too.
> They are:
> 	nptl/eintr1 (I actually don't run this because it kills the 'make check')
> 	debug/tst-backtrace5
> 	debug/tst-backtrace6
> 	nptl/tst-stack4
> 	nptl/tst-thread_local1
>
> In ILP32 mode I get 33 failures, they include the above failures (minus
> nptl/tst-thread_local1) plus:
>
> 	c++-types-check
> 	conform/ISO11/inttypes.h/conform
> 	conform/ISO11/stdint.h/conform
> 	conform/ISO99/inttypes.h/conform
> 	conform/ISO99/stdint.h/conform
> 	conform/POSIX2008/inttypes.h/conform
> 	conform/POSIX2008/stdint.h/conform
> 	conform/XOPEN2K/inttypes.h/conform
> 	conform/XOPEN2K/stdint.h/conform
> 	conform/XOPEN2K8/inttypes.h/conform
> 	conform/XOPEN2K8/stdint.h/conform
> 	elf/tst-tls1
> 	elf/tst-tls1-static
> 	elf/tst-tls2
> 	elf/tst-tls2-static
> 	elf/tst-tls3
> 	math/check-abi-libm
> 	math/test-double
> 	math/test-double-finite
> 	math/test-float
> 	math/test-float-finite
> 	misc/tst-sync_file_range
> 	nptl/tst-cancel26
> 	nptl/tst-cancel27
> 	nptl/tst-sem3
> 	rt/tst-mqueue1
> 	rt/tst-mqueue2
> 	rt/tst-mqueue4
> 	rt/tst-mqueue7
> 	stdlib/tst-makecontext3
>
> I am currently looking at these ILP32 regressions (starting with the
> tls failures) to see if I can figure out what is happening with them.
Is there some progresses on it? We could collabrate to fix those issues.

Regards

Bamvor
>
> Steve Ellcey
> sellcey@caviumnetworks.com
>

Re: ILP32 for ARM64: testing with glibc testsuite

[Andreas Schwab]

On Dez 05 2016, "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> wrote:

> Is there some progresses on it? We could collabrate to fix those issues.

All the elf/nptl/rt fails should be fixed by the recent binutils fixes.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: ILP32 for ARM64 - testing with lmbench

[Zhangjian (Bamvor)]

Hi, Catalin, Guys

Do you have suggestion of next move of upstreaming ILP32?
There are already the test results of lmbench and specint. Do you they are ok or need more data to prove no regression?
I have also noticed that there are ILP32 failures in glibc testsuite. Is it the only blocker for merge ILP32(in technology part)?

We appreciate any feedback/suggestion and hope could collaborate to improve the upstream progress.

(cc libc-alpha to get more input).

Thanks

Bamvor

On 2016/11/17 15:48, Zhangjian (Bamvor) wrote:
> Hi, Maxim
>
> On 2016/11/17 13:02, Maxim Kuvyrkov wrote:
>> Hi Bamvor,
>>
>> I'm surprised that you see this much difference from ILP32 patches on SPEC CPU2006int at all.  The SPEC CPU2006 benchmarks spend almost no time in the kernel syscalls.  I can imagine memory, TLB,
>> and cache handling in the kernel could affect CPU2006 benchmarks.  Do ILP32 patches touch code in those areas?
>>
>> Other than that, it would be interesting to check what the variance is between the 3 iterations of benchmark runs.  Could you check what relative standard deviation is between the 3 iterations --
>> (STDEV(RUN1, RUN2, RUN3) / RUNselected)?
>>
>> For reference, in my [non-ILP32] benchmarking I see 1.1% for 401.bzip2,  0.8% for 429.mcf, 0.2% for 456.hmmer, and 0.1% for 462.libquantum.
> Here is my result:
>                     ILP32_merged    ILP32_unmerged
>       401.bzip2            0.31%            0.26%
>       429.mcf              1.61%            1.36%
>       456.hmmer            1.37%            1.57%
>       462.libquantum       0.29%            0.28%
>
> Regards
>
> Bamvor
>
>>
>> --
>> Maxim Kuvyrkov
>> www.linaro.org
>>
>>
>>
>>> On Nov 17, 2016, at 7:28 AM, Zhangjian (Bamvor) <bamvor.zhangjian@huawei.com> wrote:
>>>
>>> Hi, all
>>>
>>> I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively
>>> and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found
>>> that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is
>>> enabled, compare with aarch32 el0 disabled kernel. And bzip2, mcg, hmmer,
>>> libquantum are the top four differences[1]. Note that bigger is better in
>>> specint test.
>>>
>>> In order to make sure the above results, I retest these four testcases in
>>> reportable way(reference the command in the end). The result[2] show that
>>> libquantum decrease -2.09% after ILP32 enabled and aarch32 on. I think it is in
>>> significant.
>>>
>>> The result of lmbench is not stable in my board. I plan to dig it later.
>>>
>>> [1] The following test result is tested through --size=ref --iterations=3.
>>> 1.1 Test when aarch32_el0 is enabled.
>>>                        ILP32 disabled        base line
>>>      400.perlbench            100.00%             100%
>>>      401.bzip2                 99.35%             100%
>>>      403.gcc                  100.26%             100%
>>>      429.mcf                  102.75%             100%
>>>      445.gobmk                100.00%             100%
>>>      456.hmmer                 95.66%             100%
>>>      458.sjeng                100.00%             100%
>>>      462.libquantum           100.00%             100%
>>>      471.omnetpp              100.59%             100%
>>>      473.astar                 99.66%             100%
>>>      483.xalancbmk             99.10%             100%
>>>
>>> 1.2 Test when aarch32_el0 is disabled
>>>                        ILP32 disabled         base line
>>>      400.perlbench            100.22%              100%
>>>      401.bzip2                100.95%              100%
>>>      403.gcc                  100.20%              100%
>>>      429.mcf                  100.76%              100%
>>>      445.gobmk                100.36%              100%
>>>      456.hmmer                 97.94%              100%
>>>      458.sjeng                 99.73%              100%
>>>      462.libquantum            98.72%              100%
>>>      471.omnetpp              100.86%              100%
>>>      473.astar                 99.15%              100%
>>>      483.xalancbmk            100.08%              100%
>>>
>>> [2] The following test result is tested through: runspec --config=my.cfg --size=test,train,ref --noreportable --tune=base,peak --iterations=3 bzip2 mcf hmmer libquantum
>>> 2.1 Test when aarch32_el0 is enabled.
>>>                         ILP32_enabled         base line
>>>      401.bzip2                100.82%              100%
>>>      429.mcf                  100.18%              100%
>>>      456.hmmer                 99.64%              100%
>>>      462.libquantum            97.91%              100%
>>>
>>> Regards
>>>
>>> Bamvor
>>>
>>> On 2016/10/28 20:46, Yury Norov wrote:
>>>> [Add Steve Ellcey, thanks for testing on ThunderX]
>>>>
>>>> Lmbench-3.0-a9 testing is performed on ThunderX machine to check that
>>>> ILP32 series does not add performance regressions for LP64. Test
>>>> summary is in the table below. Our measurements doesn't show
>>>> significant performance regression of LP64 if ILP32 code is merged,
>>>> both enabled or disabled.
>>>>
>>>>               ILP32 enabled   ILP32  disabled   Standard Kernel
>>>> null syscall   0.1066          0.1121            0.1121
>>>>               95.09%          100.00%
>>>>
>>>> stat           1.3947          1.3814            1.3864
>>>>               100.60%         99.64%
>>>>
>>>> fstat          0.4459          0.4344            0.4524
>>>>               98.56%          96.02%
>>>>
>>>> open/close     4.0606          4.0411            4.0453
>>>>               100.38%         99.90%
>>>>
>>>> read           0.4819          0.5014            0.5014
>>>>               96.11%          100.00%
>>>>
>>>> Tested with linux 4.8 because 4.9-rc1 is not fixed yet for ThunderX.
>>>> Other system details below.
>>>>
>>>> Yury.
>>>>
>>>> ubuntu@crb6:~$ uname -a
>>>> Linux crb6 4.8.0+ #3 SMP Thu Oct 27 11:01:32 PDT 2016 aarch64 aarch64 aarch64 GNU/Linux
>>>>
>>>> ubuntu@crb6:~$ cat /proc/meminfo
>>>> MemTotal:       132011948 kB
>>>> MemFree:        131442672 kB
>>>> MemAvailable:   130695764 kB
>>>> Buffers:           15696 kB
>>>> Cached:            88088 kB
>>>> SwapCached:            0 kB
>>>> Active:            82760 kB
>>>> Inactive:          41336 kB
>>>> Active(anon):      20880 kB
>>>> Inactive(anon):     8576 kB
>>>> Active(file):      61880 kB
>>>> Inactive(file):    32760 kB
>>>> Unevictable:           0 kB
>>>> Mlocked:               0 kB
>>>> SwapTotal:      128920572 kB
>>>> SwapFree:       128920572 kB
>>>> Dirty:                 0 kB
>>>> Writeback:             0 kB
>>>> AnonPages:         20544 kB
>>>> Mapped:            19780 kB
>>>> Shmem:              9060 kB
>>>> Slab:              78804 kB
>>>> SReclaimable:      27372 kB
>>>> SUnreclaim:        51432 kB
>>>> KernelStack:        8336 kB
>>>> PageTables:          820 kB
>>>> NFS_Unstable:          0 kB
>>>> Bounce:                0 kB
>>>> WritebackTmp:          0 kB
>>>> CommitLimit:    194926544 kB
>>>> Committed_AS:     256324 kB
>>>> VmallocTotal:   135290290112 kB
>>>> VmallocUsed:           0 kB
>>>> VmallocChunk:          0 kB
>>>> AnonHugePages:         0 kB
>>>> ShmemHugePages:        0 kB
>>>> ShmemPmdMapped:        0 kB
>>>> CmaTotal:              0 kB
>>>> CmaFree:               0 kB
>>>> HugePages_Total:       0
>>>> HugePages_Free:        0
>>>> HugePages_Rsvd:        0
>>>> HugePages_Surp:        0
>>>> Hugepagesize:       2048 kB
>>>>
>>>> ubuntu@crb6:~$ cat /proc/cpuinfo
>>>> processor    : 0
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 1
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 2
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 3
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 4
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 5
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 6
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 7
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 8
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 9
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 10
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 11
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 12
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 13
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 14
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 15
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 16
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 17
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 18
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 19
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 20
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 21
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 22
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 23
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 24
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 25
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 26
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 27
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 28
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 29
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 30
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 31
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 32
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 33
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 34
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 35
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 36
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 37
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 38
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 39
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 40
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 41
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 42
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 43
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 44
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 45
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 46
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>> processor    : 47
>>>> BogoMIPS    : 200.00
>>>> Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
>>>> CPU implementer    : 0x43
>>>> CPU architecture: 8
>>>> CPU variant    : 0x1
>>>> CPU part    : 0x0a1
>>>> CPU revision    : 0
>>>>
>>>
>>
>

Re: ILP32 for ARM64: testing with glibc testsuite

[Zhangjian (Bamvor)]

On 2016/12/5 18:07, Andreas Schwab wrote:
> On Dez 05 2016, "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> wrote:
>
>> Is there some progresses on it? We could collabrate to fix those issues.
>
> All the elf/nptl/rt fails should be fixed by the recent binutils fixes.
Cool. How about the conform and other failures?

Regards

Bamvor
>
> Andreas.
>

Re: ILP32 for ARM64: testing with glibc testsuite

[Yury Norov]

On Mon, Dec 05, 2016 at 06:24:11PM +0800, Zhangjian (Bamvor) wrote:
> 
> 
> On 2016/12/5 18:07, Andreas Schwab wrote:
> >On Dez 05 2016, "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> wrote:
> >
> >>Is there some progresses on it? We could collabrate to fix those issues.
> >
> >All the elf/nptl/rt fails should be fixed by the recent binutils fixes.
> Cool. How about the conform and other failures?

I think conform is only my local problem. I use pretty non-standard
environment for build and testing - cross-compilation + qemu. Steve
builds and runs tests natively, and he doesn't see that regressions.

Yury

Re: ILP32 for ARM64: testing with glibc testsuite

[Andreas Schwab]

On Dez 05 2016, Steve Ellcey <sellcey@caviumnetworks.com> wrote:

> FAIL: nptl/tst-cancel26
> FAIL: nptl/tst-cancel27

> FAIL: rt/tst-mqueue1
> FAIL: rt/tst-mqueue2
> FAIL: rt/tst-mqueue4
> FAIL: rt/tst-mqueue7

I don't see these failures.  Maybe you need to rebuild libgcc?

https://build.opensuse.org/package/live_build_log/devel:ARM:AArch64:ILP32/glibc-testsuite/standard/aarch64_ilp32

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: ILP32 for ARM64 - testing with lmbench

[Yury Norov]

On Mon, Dec 05, 2016 at 02:13:12PM +0000, Catalin Marinas wrote:
> On Mon, Dec 05, 2016 at 06:16:09PM +0800, Zhangjian (Bamvor) wrote:
> > Do you have suggestion of next move of upstreaming ILP32?
> 
> I mentioned the steps a few time before. I'm pasting them again here:
> 
> 1. Complete the review of the Linux patches and ABI (no merge yet)
> 2. Review the corresponding glibc patches (no merge yet)
> 3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more
>    than just busybox) to be able to reproduce the testing in ARM
> 4. More testing (LTP, trinity, performance regressions etc.)
> 5. Move the ILP32 PCS out of beta (based on the results from 4)
> 6. Check the market again to see if anyone still needs ILP32
> 7. Based on 6, decide whether to merge the kernel and glibc patches
> 
> What's not explicitly mentioned in step 4 is glibc testing. Point 5 is
> ARM's responsibility (toolchain folk).
> 
> > There are already the test results of lmbench and specint. Do you they
> > are ok or need more data to prove no regression?
> 
> I would need to reproduce the tests myself, see step 3.

Hi Catalin,

> 3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more
>    than just busybox) to be able to reproduce the testing in ARM

This is the Andrew's toolchain I use to build kernel, GLIBC, binutils etc:
https://drive.google.com/open?id=0B93nHerV55yNVlVKaXpOOHQtbW8
It's not the latest build but it works well to me.

This archive contains 4.9-rc8 kernel, initrd, sys-root, qemu image based on
ilp32 busybox. 
https://drive.google.com/open?id=0B93nHerV55yNbVo0bko0bWlQeFE

I can start linux on qemu and run basic commands and tests in ilp32
mode. This is my first attempt to create rootfs, and this is very basic
busybox + sys-root.  But it lets me start lp64 and ilp32 apps (find
example there). If you need something more, let me know and I'll add
it. You can also use any professional distro with this ilp32-enabled
kernel, just copy sys-root there (like I actually do - I run Ubuntu
14 daily). 

BTW. This is of course good idea to build and test ilp32 user
environment, but in real life I think ilp32 apps will work in lp64
userspace.

> 4. More testing (LTP, trinity, performance regressions etc.)

I also built and ran trinity. After ~24 hours I found all trinity
threads stalled for lp64, and after another 24 hours I found it
running but slower for ilp32. Kernel was alive in both cases. 

Yury.