linux-kernel - Re: [Buildroot] [Automated-testing] Call for nommu LTP maintainer [was: Re: [PATCH 00/36] Remove UCLINUX from LTP]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZaU_oMTrmXxy0Dub@rei>
Date: Mon, 15 Jan 2024 15:22:24 +0100
From: Cyril Hrubis <chrubis@...e.cz>
To: Waldemar Brodkorb <wbx@...nadk.org>
Cc: Petr Vorel <pvorel@...e.cz>, Greg Ungerer <gerg@...ux-m68k.org>,
	Rob Landley <rob@...dley.net>, Tim Bird <tim.bird@...y.com>,
	Niklas Cassel <niklas.cassel@....com>,
	Andrea Cervesato <andrea.cervesato@...e.com>,
	Jonathan Corbet <corbet@....net>,
	Linux-sh list <linux-sh@...r.kernel.org>,
	Christophe Lyon <christophe.lyon@...aro.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Li Wang <liwang@...hat.com>,
	"linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Linux ARM <linux-arm-kernel@...ts.infradead.org>,
	John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
	linux-riscv <linux-riscv@...ts.infradead.org>,
	"buildroot@...ldroot.org" <buildroot@...ldroot.org>,
	"ltp@...ts.linux.it" <ltp@...ts.linux.it>,
	"automated-testing@...ts.yoctoproject.org" <automated-testing@...ts.yoctoproject.org>
Subject: Re: [Buildroot] [Automated-testing] Call for nommu LTP maintainer
 [was: Re: [PATCH 00/36] Remove UCLINUX from LTP]

Hi!
> RANLIB libltp.a
> /home/wbx/arm/toolchain_st-stm32f746g_uclibc-ng_cortex_m7_soft_eabi_thumb_nommu/usr/lib/gcc/arm-openadk-uclinuxfdpiceabi/13.2.0/../../../../arm-openadk-uclinuxfdpiceabi/bin/ld: ../../lib/libltp.a(tst_res.o): in function `tst_fork':
> /home/wbx/arm/build_st-stm32f746g_uclibc-ng_cortex_m7_soft_eabi_thumb_nommu/w-ltp-20230929-1/ltp-full-20230929/lib/tst_res.c:430:(.text+0x952): undefined reference to `fork'
> /home/wbx/arm/toolchain_st-stm32f746g_uclibc-ng_cortex_m7_soft_eabi_thumb_nommu/usr/lib/gcc/arm-openadk-uclinuxfdpiceabi/13.2.0/../../../../arm-openadk-uclinuxfdpiceabi/bin/ld: ../../lib/libltp.a(tst_test.o): in function `fork_testrun':
> /home/wbx/arm/build_st-stm32f746g_uclibc-ng_cortex_m7_soft_eabi_thumb_nommu/w-ltp-20230929-1/ltp-full-20230929/lib/tst_test.c:1597:(.text+0xf4e): undefined reference to `fork'
> /home/wbx/arm/toolchain_st-stm32f746g_uclibc-ng_cortex_m7_soft_eabi_thumb_nommu/usr/lib/gcc/arm-openadk-uclinuxfdpiceabi/13.2.0/../../../../arm-openadk-uclinuxfdpiceabi/bin/ld: ../../lib/libltp.a(tst_test.o): in function `safe_fork':
> /home/wbx/arm/build_st-stm32f746g_uclibc-ng_cortex_m7_soft_eabi_thumb_nommu/w-ltp-20230929-1/ltp-full-20230929/lib/tst_test.c:435:(.text+0x345c): undefined reference to `fork'
> collect2: error: ld returned 1 exit status
> gmake[8]: *** [../../include/mk/rules.mk:45: test01] Error 1
> gmake[7]: *** [../include/mk/generic_trunk_target.inc:108: all] Error 2
> gmake[6]: *** [Makefile:94: lib-all] Error 2
> gmake[5]: *** [/home/wbx/arm/mk/pkg-bottom.mk:141: /home/wbx/arm/build_st-stm32f746g_uclibc-ng_cortex_m7_soft_eabi_thumb_nommu/w-ltp-20230929-1/ltp-full-20230929/.build_done] Error 2
> gmake[4]: *** [Makefile:61: ltp-compile] Error 2
> gmake[3]: *** [mk/build.mk:221: package/compile] Error 2
> gmake[2]: *** [/home/wbx/arm/mk/build.mk:176: world] Error 2
> 
> So there is really work to be done to make the existing code work on noMMU.

The new test library in LTP runs the actuall test in a child process,
which provides all kinds of benefits, most notably isolation of the
setup/cleanup/result reporting from actuall test code that may crash.
This is of course useless on nommu targets, so I suppose that we would
need a test library tailored for nommu first. However the testcases
themselve fork quite often too. Which means that some kind of parameter
marshaling into a string needs to be done for such tests as well each
test needs to be adjusted to use that in a case of nommu. All in all
getting into a state where majority of tests runs on nommu would be a
major effort.

-- 
Cyril Hrubis
chrubis@...e.cz