Re: [selftests] 7cb32086e5: kernel-selftests.x86.check_initial_reg_state_32.fail

[Yauheni Kaliuta <yauheni.kaliuta@redhat.com>]

Hi, Shuah!

>>>>> On Fri, 10 Jul 2020 08:18:49 -0600, Shuah Khan  wrote:

 > On 7/10/20 12:02 AM, Yauheni Kaliuta wrote:
 >> On Thu, Jul 9, 2020 at 6:36 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
 >>> 
 >>> On 7/9/20 12:49 AM, kernel test robot wrote:
 >>>> Greeting,
 >>>> 
 >>>> FYI, we noticed the following commit (built with gcc-9):
 >>>> 
 >>>> commit: 7cb32086e59b514a832a3e11f5370d37e7cfe022 ("selftests:
 >>>> simplify run_tests")
 >>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
 >>>> 
 >>>> 
 >>> 
 >>> Thanks for the report. I will drop this patch for now from next.
 >>> 
 >>> Yauheni,
 >>> 
 >>> This patch broke x86 32-bit test run
 >>> make run_tests -C x86
 >>> 
 >>> Please resubmit the patch with the fix.
 >> 
 >> I did not check carefully the report, but isn't it expected that some
 >> tests are moved after the patch since they originally were placed
 >> incorrectly?
 >> 
 >> 
 > The failure doesn't have anything to do with test being moved. You can
 > reproduce this very easily by running make as shown below in x86 dir
 > under tools/testing/selftests

 > make run_tests -C x86

 > I reproduced the problem with your and patch and verified that the
 > problem tracks your patch. I dropped the patch from linux-next
 > Your other two patches in the series are fine.

 > In any case, this patch isn't really adding any functionality and
 > is a good cleanup. Let's do the cleanup right or not.


Checked.

That is because with the patch both lib.mk and x86/Makefile add
the $(OUTPUT) prefix.

So the question is to agree about the convention, should lib.mk
targets expect short test names for TEST_PROGS or full path from
the subtests' Makefiles.

The existing code is hackish (incorrectly -- adding $(OUTPUT)
only to the first list members -- tries to handle it only for
out-of-tree build).

I can make the patch without adding $(OUTPUT). It will require to
fix possible tests which provided only one test and rely on that
behaviour for the OOT build. Do you have an easy way to get a
list of such tests?


-- 
WBR,
Yauheni Kaliuta