All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague.
Date: Sun, 16 Dec 2018 16:42:02 -0500	[thread overview]
Message-ID: <20181216214202.GQ11670@windriver.com> (raw)
In-Reply-To: <20171229181830.GH10431@windriver.com>

[Re: [Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague.] On 29/12/2017 (Fri 13:18) Paul Gortmaker wrote:

> [Re: [Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague.] On 29/12/2017 (Fri 10:47) Josh Poimboeuf wrote:
> 
> > This seems to be related to a kconfig quirk where only silentoldconfig
> > updates the include/config/auto.conf file.  The other config targets
> > (oldconfig, defconfig, etc) don't touch it.  It seems intentional, but I
> > have no idea why.
> > 
> > That causes the Makefile to get stale data for 'CONFIG_*' variables when
> > it includes auto.conf.  So I don't think this is specific to the ORC
> > check.  It seems like it could also cause bugs elsewhere.
> 
> OK, good - you agree with my initial diagnosis of stale auto.conf then.
> Not sure what Randy was testing when he said he couldn't reproduce it.
> 
> > The below (ugly) patch fixes it, though I'm not sure this is the best
> > way to do it.  We probably need Masahiro or Michal to chime in here.
> 
> Yep, that is why I intentionally put the kbuild folks on the To/Cc of
> the original report (and ran away screaming at the prospect of debugging
> Makefiles on xmas day).  But with holidays and all, it might not be
> until early January before they have a chance to reply.

It is nearly a year later and we still have this false positive.

paul@sm:~/git/linux-head$ make -j12 > /dev/null
Makefile:966: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y,
 please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop.
paul@sm:~/git/linux-head$ grep UNWINDER_ORC .config
# CONFIG_UNWINDER_ORC is not set

We do know a bit more now -- the auto.conf issue has been independently
confirmed and "fixed" for other subsystems/issues since, like RETPOLINE:

 ---------------------
  commit 25896d073d8a0403b07e6dec56f58e6c33678207
  Author: Masahiro Yamada <yamada.masahiro@socionext.com>
  Date:   Wed Dec 5 15:27:19 2018 +0900
   
    x86/build: Fix compiler support check for CONFIG_RETPOLINE

    It is troublesome to add a diagnostic like this to the Makefile
    parse stage because the top-level Makefile could be parsed with
    a stale include/config/auto.conf.

    Once you are hit by the error about non-retpoline compiler, the
    compilation still breaks even after disabling CONFIG_RETPOLINE.
 ---------------------

I'm not sure if we want to treat this on a per config option each time
again and again, or undertake a more global kbuild approach, but it does
warrant a mention and a re-examination before we "solve" this again.

Paul.
--

WARNING: multiple messages have this Message-ID (diff)
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	<linux-kbuild@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague.
Date: Sun, 16 Dec 2018 16:42:02 -0500	[thread overview]
Message-ID: <20181216214202.GQ11670@windriver.com> (raw)
In-Reply-To: <20171229181830.GH10431@windriver.com>

[Re: [Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague.] On 29/12/2017 (Fri 13:18) Paul Gortmaker wrote:

> [Re: [Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague.] On 29/12/2017 (Fri 10:47) Josh Poimboeuf wrote:
> 
> > This seems to be related to a kconfig quirk where only silentoldconfig
> > updates the include/config/auto.conf file.  The other config targets
> > (oldconfig, defconfig, etc) don't touch it.  It seems intentional, but I
> > have no idea why.
> > 
> > That causes the Makefile to get stale data for 'CONFIG_*' variables when
> > it includes auto.conf.  So I don't think this is specific to the ORC
> > check.  It seems like it could also cause bugs elsewhere.
> 
> OK, good - you agree with my initial diagnosis of stale auto.conf then.
> Not sure what Randy was testing when he said he couldn't reproduce it.
> 
> > The below (ugly) patch fixes it, though I'm not sure this is the best
> > way to do it.  We probably need Masahiro or Michal to chime in here.
> 
> Yep, that is why I intentionally put the kbuild folks on the To/Cc of
> the original report (and ran away screaming at the prospect of debugging
> Makefiles on xmas day).  But with holidays and all, it might not be
> until early January before they have a chance to reply.

It is nearly a year later and we still have this false positive.

paul@sm:~/git/linux-head$ make -j12 > /dev/null
Makefile:966: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y,
 please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop.
paul@sm:~/git/linux-head$ grep UNWINDER_ORC .config
# CONFIG_UNWINDER_ORC is not set

We do know a bit more now -- the auto.conf issue has been independently
confirmed and "fixed" for other subsystems/issues since, like RETPOLINE:

 ---------------------
  commit 25896d073d8a0403b07e6dec56f58e6c33678207
  Author: Masahiro Yamada <yamada.masahiro@socionext.com>
  Date:   Wed Dec 5 15:27:19 2018 +0900
   
    x86/build: Fix compiler support check for CONFIG_RETPOLINE

    It is troublesome to add a diagnostic like this to the Makefile
    parse stage because the top-level Makefile could be parsed with
    a stale include/config/auto.conf.

    Once you are hit by the error about non-retpoline compiler, the
    compilation still breaks even after disabling CONFIG_RETPOLINE.
 ---------------------

I'm not sure if we want to treat this on a per config option each time
again and again, or undertake a more global kbuild approach, but it does
warrant a mention and a re-examination before we "solve" this again.

Paul.
--

  parent reply	other threads:[~2018-12-16 21:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-26  4:30 [Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague Paul Gortmaker
2017-12-26  4:30 ` Paul Gortmaker
2017-12-28 19:29 ` Randy Dunlap
2017-12-29  2:13   ` Paul Gortmaker
2017-12-29  2:13     ` Paul Gortmaker
2017-12-29 16:47     ` Josh Poimboeuf
2017-12-29 18:18       ` Paul Gortmaker
2017-12-29 18:18         ` Paul Gortmaker
2017-12-29 18:40         ` vcaputo
2018-12-16 21:42         ` Paul Gortmaker [this message]
2018-12-16 21:42           ` Paul Gortmaker
2018-12-18  4:56           ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181216214202.GQ11670@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=mingo@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.