Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <B0DD4BA059591F13+4c61dc98-4d70-4ab2-b4ca-81c0e6596482@tinylab.org>
Date:   Sun, 27 Aug 2023 02:29:53 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] selftests/nolibc: fix up O= option support
Content-Language: en-GB
To:     Zhangjin Wu <falcon@tinylab.org>, w@1wt.eu
Cc:     arnd@arndb.de, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org, linux@weissschuh.net,
        thomas@t-8ch.de, Yuan Tan <tanyuan@tinylab.org>
References: <20230806121721.30774-1-falcon@tinylab.org>
 <20230826043046.53692-1-falcon@tinylab.org>
From:   Yuan Tan <tanyuan@tinylab.org>
In-Reply-To: <20230826043046.53692-1-falcon@tinylab.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Feedback-ID: bizesmtpipv:tinylab.org:qybglogicsvrgz:qybglogicsvrgz5a-1
Precedence: bulk

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@linux-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