On Fri, Jun 18, 2021 at 4:30 AM Rong Chen <rong.a.chen@xxxxxxxxx> wrote:
> On 6/7/21 3:19 PM, Arnd Bergmann wrote:
> > On Mon, Jun 7, 2021 at 8:27 AM Rong Chen <rong.a.chen@xxxxxxxxx> wrote:
> >> On 6/5/21 7:08 PM, Arnd Bergmann wrote:
>
> Thanks for the detailed explanation, and we have asked advice of
> internal developers,
> we'll enable COMPILE_TEST for randconfig, and check the failures if
> COMPILE_TEST=n
> in future.
Awesome, thanks a lot.
> BTW is there any issue that found by randconfig with COMPILE_TEST=n
> should be reported?
It's definitely possible, but I expect that to be rare enough that
investing your
time elsewhere is more helpful. If you do wish to keep testing this
configuration,
this is how I would approach it:
- Since you have a database of known warnings and errors, a good thing to try
would be analyze it and figure out the types of warning that predominantly
happen with COMPILE_TEST=n randconfigs, but still happen occasionally
with COMPILE_TEST=y, as those are more likely real bugs.
- possibly annotate them to find which particular Kconfig option that
gets guarded
by COMPILE_TEST causes which output. This should be possible because
there are only a small number of such options.
- Run a small percentage of randconfig builds with COMPILE_TEST=n and the
cross-check the output against the known classes of diagnostic output
rather than individual lines.
Arnd
