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] [thread-next>] [day] [month] [year] [list]
Message-ID: <B0DD4BA059591F13+4c61dc98-4d70-4ab2-b4ca-81c0e6596482@tinylab.org>
Date:   Sun, 27 Aug 2023 02:29:53 +0800
From:   Yuan Tan <tanyuan@...ylab.org>
To:     Zhangjin Wu <falcon@...ylab.org>, w@....eu
Cc:     arnd@...db.de, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, linux@...ssschuh.net,
        thomas@...ch.de, Yuan Tan <tanyuan@...ylab.org>
Subject: Re: [PATCH v2 3/3] selftests/nolibc: fix up O= option support

Hi Zhangjin and Willy,

On 8/26/2023 12:30 PM, Zhangjin Wu wrote:
> Hi, Willy
>
>>> On Sat, Aug 05, 2023 at 02:13:11PM +0800, Zhangjin Wu wrote:
>>>> To avoid pollute the source code tree and avoid mrproper for every
>>>> architecture switch, the O= argument must be supported.
>>>>
>>>> Both IMAGE and .config are from the building directory, let's use
>>>> objtree instead of srctree for them.
>>>>
>>>> If no O= option specified, means building kernel in source code tree,
>>>> objtree should be srctree in such case.
>>>>
>>>> To support relative path, as suggested by Thomas, $(COMMAND_O) is used
>>>> to pass the O=$(ABSOLUTE_O) to the $(MAKE) commands.
>>> Zhangjin, I cannot get this one to work, regardless of what I try:
>>>
>>>     $ make -j8 O=$PWD/output-i386 nolibc-test XARCH=i386 CROSS_COMPILE=/f/tc/nolibc/gcc-12.3.0-nolibc/i386-linux/bin/i386-linux- CC=/f/tc/nolibc/gcc-12.3.0-nolibc/i386-linux/bin/i386-linux-gcc
>>>     (...)
>>>     CC      nolibc-test
>>>     In file included from sysroot/i386/include/stdio.h:14,
>>>                      from nolibc-test.c:13:
>>>     sysroot/i386/include/errno.h:10:10: fatal error: asm/errno.h: No such file or directory
>>>        10 | #include <asm/errno.h>
>>>           |          ^~~~~~~~~~~~~
>>>     compilation terminated.
>>>
>> Willy, I also just reproduced the issue, seems only i386 sysroot has no
>> asm/errno.h, will check why it is no rightly installed later.
>>
>>      $ find sysroot/ -name "errno.h"
>>      sysroot/arm/include/errno.h
>>      sysroot/arm/include/asm-generic/errno.h
>>      sysroot/arm/include/asm/errno.h
>>      sysroot/arm/include/linux/errno.h
>>      sysroot/riscv/include/errno.h
>>      sysroot/riscv/include/asm-generic/errno.h
>>      sysroot/riscv/include/asm/errno.h
>>      sysroot/riscv/include/linux/errno.h
>>      sysroot/s390/include/errno.h
>>      sysroot/s390/include/asm-generic/errno.h
>>      sysroot/s390/include/asm/errno.h
>>      sysroot/s390/include/linux/errno.h
>>      sysroot/arm64/include/errno.h
>>      sysroot/arm64/include/asm-generic/errno.h
>>      sysroot/arm64/include/asm/errno.h
>>      sysroot/arm64/include/linux/errno.h
>>      sysroot/mips/include/errno.h
>>      sysroot/mips/include/asm-generic/errno.h
>>      sysroot/mips/include/asm/errno.h
>>      sysroot/mips/include/linux/errno.h
>>      sysroot/x86_64/include/errno.h
>>      sysroot/x86_64/include/asm-generic/errno.h
>>      sysroot/x86_64/include/asm/errno.h
>>      sysroot/x86_64/include/linux/errno.h
>>      sysroot/i386/include/errno.h
>>      sysroot/i386/include/asm-generic/errno.h
>>      sysroot/i386/include/linux/errno.h
>>      sysroot/powerpc/include/errno.h
>>      sysroot/powerpc/include/asm-generic/errno.h
>>      sysroot/powerpc/include/asm/errno.h
>>      sysroot/powerpc/include/linux/errno.h
>>
>>> I'll leave it aside for now as I've spent way longer than I hoped on
>>> these series. I could take the previous two patches however.
>>>
>> Ok, let's ignore this one, I will find why sysroot not install well for i386.
>>
> Thanks to Yuan, he have done some testing and have found the root cause, that
> is mrproper on top-level source code tree is required before installing
> sysroot, otherwise, the 'generated' headers will not be installed (removed by
> scripts/Makefile.asm-generic).

More specifically, building kernel will generate 
'linux/arch/x86/include/generated/uapi/asm/errno.h', which prevents 
nolibc-test with O= generate 
'output-x86/arch/x86/include/generated/asm/errno.h'.

>
> After mrproper (not with O=out, must on top-level source code tree), the
> asm/errno.h will be there:
>
>      ubuntu@...ux-lab:/labs/linux-lab/src/linux-stable/tools/testing/selftests/nolibc$ find sysroot/ -name "errno.h"
>      sysroot/i386/include/errno.h
>      sysroot/i386/include/asm-generic/errno.h
>      sysroot/i386/include/asm/errno.h             --> here it is
>      sysroot/i386/include/linux/errno.h
>      sysroot/x86/include/errno.h
>      sysroot/x86/include/asm-generic/errno.h
>      sysroot/x86/include/asm/errno.h              --> here it is
>      sysroot/x86/include/linux/errno.h
>
> That also means, to use O=out for run-user, we also need to use O=out for
> defconfig (and kernel ...) too, otherwise, the top-level source code tree will
> be polluated.
>
> Seems a manual mrproper on top-level source code tree is always required for a
> new iteration, so, it may be ok to pick this patch with a note on the potential
> error.

There are two potential solutions for addressing this issue.

The first option involves copying 
'linux/arch/x86/include/generated/uapi/asm/' to 'sysroot/x86/include/' 
during the make of target headers_standalone.

The second approach entails displaying an error message when the code 
tree is not clean and prompting users to manually execute 'make 
mrproper'. In this case, we can utilize the target 'outputmakefile' from 
the root makefile directly.

Willy, which method do you prefer? Do you have any alternative 
suggestions? :)


Besides. using x86_64-linux-gnu- won't reproduce this issue. It searched 
and found 'asm/errno.h' in '/usr/include/x86_64-linux-gnu', whereas 
'x86_64-linux' lacks these libraries.

>
> Best Regards,
> Zhangjin
>
>> Thanks,
>> Zhangjin
>>
>>> Thanks,
>>> Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ