There is a regression new to 4.15 that happens in a rather common
workflow which results in the frustrating situation where the user has
clearly disabled UNWINDER_ORC in their ".config" file, and yet they
still get the immediate false error saying they need libelf-dev since
"CONFIG_UNWINDER_ORC=y" is still set, and hence they can not build.
The regression requires UNWINDER_ORC=y (now the default in commit
fc72ae40e303) followed by the user subsequently disabling it, which is
common if the user doesn't have libelf-dev and doesn't care about ORC.
This happens because the recently added test in the top level Makefile
assumes that ,config data will be mapped into include/config/auto.conf
either by the end user running "make oldconfig" or the Makefile itself
detecting that "silentoldconfig" should be run. As the simple
reproducer below shows, this clearly does not happen as expected.
Note that the test for CONFIG_STACK_VALIDATION and libelf-dev in the
same place in the Makefile is broken in the same way, but since it is a
warning and not an error, nobody cared about the bogus false positives.
Since there is no way I'm going to debug Makefile stuff on Christmas
Day, I figured that I should at least report it intstead. The work
around is to save your .config and run a "make distclean" or manually
clobber the stale include/config/auto.conf or similar. But a frustrated
user wouldn't know that w/o the root cause...
--------------------- reproducer ------------------------
paul@gw:~/git/linux-head$ git describe
v4.15-rc5
paul@gw:~/git/linux-head$ make distclean
paul@gw:~/git/linux-head$ make defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
paul@gw:~/git/linux-head$ make
scripts/kconfig/conf --silentoldconfig Kconfig
Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
paul@gw:~/git/linux-head$ vi .config # disable ORC in favour of FRAME_POINTER
paul@gw:~/git/linux-head$ make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
#
# configuration written to .config
#
paul@gw:~/git/linux-head$ grep UNWINDER .config
# CONFIG_UNWINDER_ORC is not set
CONFIG_UNWINDER_FRAME_POINTER=y
paul@gw:~/git/linux-head$ make
Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
paul@gw:~/git/linux-head$ ls -l .config include/config/auto.conf
-rw-rw-r-- 1 paul paul 115953 Dec 25 22:48 .config
-rw-rw-r-- 1 paul paul 33069 Dec 25 22:46 include/config/auto.conf
paul@gw:~/git/linux-head$ grep UNWINDER include/config/auto.conf
CONFIG_UNWINDER_ORC=y
paul@gw:~/git/linux-head$
--------------------- reproducer ------------------------
On 12/25/2017 08:30 PM, Paul Gortmaker wrote:
> There is a regression new to 4.15 that happens in a rather common
> workflow which results in the frustrating situation where the user has
> clearly disabled UNWINDER_ORC in their ".config" file, and yet they
> still get the immediate false error saying they need libelf-dev since
> "CONFIG_UNWINDER_ORC=y" is still set, and hence they can not build.
>
> The regression requires UNWINDER_ORC=y (now the default in commit
> fc72ae40e303) followed by the user subsequently disabling it, which is
> common if the user doesn't have libelf-dev and doesn't care about ORC.
>
> This happens because the recently added test in the top level Makefile
> assumes that ,config data will be mapped into include/config/auto.conf
> either by the end user running "make oldconfig" or the Makefile itself
> detecting that "silentoldconfig" should be run. As the simple
> reproducer below shows, this clearly does not happen as expected.
>
> Note that the test for CONFIG_STACK_VALIDATION and libelf-dev in the
> same place in the Makefile is broken in the same way, but since it is a
> warning and not an error, nobody cared about the bogus false positives.
Yeah, that's odd.
> Since there is no way I'm going to debug Makefile stuff on Christmas
> Day, I figured that I should at least report it intstead. The work
> around is to save your .config and run a "make distclean" or manually
> clobber the stale include/config/auto.conf or similar. But a frustrated
> user wouldn't know that w/o the root cause...
>
I have tried to reproduce this multiple times but cannot do so.
It remains with:
> grep UNWINDER .config
# CONFIG_UNWINDER_ORC is not set
CONFIG_UNWINDER_FRAME_POINTER=y
>
> --------------------- reproducer ------------------------
>
> paul@gw:~/git/linux-head$ git describe
> v4.15-rc5
> paul@gw:~/git/linux-head$ make distclean
> paul@gw:~/git/linux-head$ make defconfig
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/kconfig/conf.o
> SHIPPED scripts/kconfig/zconf.tab.c
> SHIPPED scripts/kconfig/zconf.lex.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> *** Default configuration is based on 'x86_64_defconfig'
> #
> # configuration written to .config
> #
> paul@gw:~/git/linux-head$ make
> scripts/kconfig/conf --silentoldconfig Kconfig
> Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
> paul@gw:~/git/linux-head$ vi .config # disable ORC in favour of FRAME_POINTER
> paul@gw:~/git/linux-head$ make oldconfig
> scripts/kconfig/conf --oldconfig Kconfig
> #
> # configuration written to .config
> #
> paul@gw:~/git/linux-head$ grep UNWINDER .config
> # CONFIG_UNWINDER_ORC is not set
> CONFIG_UNWINDER_FRAME_POINTER=y
> paul@gw:~/git/linux-head$ make
> Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
> paul@gw:~/git/linux-head$ ls -l .config include/config/auto.conf
> -rw-rw-r-- 1 paul paul 115953 Dec 25 22:48 .config
> -rw-rw-r-- 1 paul paul 33069 Dec 25 22:46 include/config/auto.conf
> paul@gw:~/git/linux-head$ grep UNWINDER include/config/auto.conf
> CONFIG_UNWINDER_ORC=y
> paul@gw:~/git/linux-head$
>
> --------------------- reproducer ------------------------
--
~Randy
[Re: [Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague.] On 28/12/2017 (Thu 11:29) Randy Dunlap wrote:
> On 12/25/2017 08:30 PM, Paul Gortmaker wrote:
> > There is a regression new to 4.15 that happens in a rather common
> > workflow which results in the frustrating situation where the user has
> > clearly disabled UNWINDER_ORC in their ".config" file, and yet they
> > still get the immediate false error saying they need libelf-dev since
> > "CONFIG_UNWINDER_ORC=y" is still set, and hence they can not build.
> >
> > The regression requires UNWINDER_ORC=y (now the default in commit
> > fc72ae40e303) followed by the user subsequently disabling it, which is
> > common if the user doesn't have libelf-dev and doesn't care about ORC.
> >
> > This happens because the recently added test in the top level Makefile
> > assumes that ,config data will be mapped into include/config/auto.conf
> > either by the end user running "make oldconfig" or the Makefile itself
> > detecting that "silentoldconfig" should be run. As the simple
> > reproducer below shows, this clearly does not happen as expected.
> >
> > Note that the test for CONFIG_STACK_VALIDATION and libelf-dev in the
> > same place in the Makefile is broken in the same way, but since it is a
> > warning and not an error, nobody cared about the bogus false positives.
>
> Yeah, that's odd.
>
> > Since there is no way I'm going to debug Makefile stuff on Christmas
> > Day, I figured that I should at least report it intstead. The work
> > around is to save your .config and run a "make distclean" or manually
> > clobber the stale include/config/auto.conf or similar. But a frustrated
> > user wouldn't know that w/o the root cause...
> >
>
> I have tried to reproduce this multiple times but cannot do so.
> It remains with:
>
> > grep UNWINDER .config
> # CONFIG_UNWINDER_ORC is not set
> CONFIG_UNWINDER_FRAME_POINTER=y
As it should. Please re-read the reproducer and the above. The data in
the .config is exactly as it should be. The include/config/auto.conf
having stale data with ORC still listed as enabled is the issue.
Also note you need a machine with libelf-dev not installed, at the risk
of stating the obvious.
Paul.
--
>
> >
> > --------------------- reproducer ------------------------
> >
> > paul@gw:~/git/linux-head$ git describe
> > v4.15-rc5
> > paul@gw:~/git/linux-head$ make distclean
> > paul@gw:~/git/linux-head$ make defconfig
> > HOSTCC scripts/basic/fixdep
> > HOSTCC scripts/kconfig/conf.o
> > SHIPPED scripts/kconfig/zconf.tab.c
> > SHIPPED scripts/kconfig/zconf.lex.c
> > HOSTCC scripts/kconfig/zconf.tab.o
> > HOSTLD scripts/kconfig/conf
> > *** Default configuration is based on 'x86_64_defconfig'
> > #
> > # configuration written to .config
> > #
> > paul@gw:~/git/linux-head$ make
> > scripts/kconfig/conf --silentoldconfig Kconfig
> > Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
> > paul@gw:~/git/linux-head$ vi .config # disable ORC in favour of FRAME_POINTER
> > paul@gw:~/git/linux-head$ make oldconfig
> > scripts/kconfig/conf --oldconfig Kconfig
> > #
> > # configuration written to .config
> > #
> > paul@gw:~/git/linux-head$ grep UNWINDER .config
> > # CONFIG_UNWINDER_ORC is not set
> > CONFIG_UNWINDER_FRAME_POINTER=y
> > paul@gw:~/git/linux-head$ make
> > Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
> > paul@gw:~/git/linux-head$ ls -l .config include/config/auto.conf
> > -rw-rw-r-- 1 paul paul 115953 Dec 25 22:48 .config
> > -rw-rw-r-- 1 paul paul 33069 Dec 25 22:46 include/config/auto.conf
> > paul@gw:~/git/linux-head$ grep UNWINDER include/config/auto.conf
> > CONFIG_UNWINDER_ORC=y
> > paul@gw:~/git/linux-head$
> >
> > --------------------- reproducer ------------------------
>
>
> --
> ~Randy
On Thu, Dec 28, 2017 at 09:13:24PM -0500, Paul Gortmaker wrote:
> > > There is a regression new to 4.15 that happens in a rather common
> > > workflow which results in the frustrating situation where the user has
> > > clearly disabled UNWINDER_ORC in their ".config" file, and yet they
> > > still get the immediate false error saying they need libelf-dev since
> > > "CONFIG_UNWINDER_ORC=y" is still set, and hence they can not build.
> > >
> > > The regression requires UNWINDER_ORC=y (now the default in commit
> > > fc72ae40e303) followed by the user subsequently disabling it, which is
> > > common if the user doesn't have libelf-dev and doesn't care about ORC.
> > >
> > > This happens because the recently added test in the top level Makefile
> > > assumes that ,config data will be mapped into include/config/auto.conf
> > > either by the end user running "make oldconfig" or the Makefile itself
> > > detecting that "silentoldconfig" should be run. As the simple
> > > reproducer below shows, this clearly does not happen as expected.
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.
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.
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 297c1bf35140..3a0d92040a9c 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -21,18 +21,23 @@ unexport CONFIG_
xconfig: $(obj)/qconf
$< $(silent) $(Kconfig)
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
gconfig: $(obj)/gconf
$< $(silent) $(Kconfig)
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
menuconfig: $(obj)/mconf
$< $(silent) $(Kconfig)
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
config: $(obj)/conf
$< $(silent) --oldaskconfig $(Kconfig)
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
nconfig: $(obj)/nconf
$< $(silent) $(Kconfig)
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
silentoldconfig: $(obj)/conf
$(Q)mkdir -p include/config include/generated
@@ -85,6 +90,7 @@ PHONY += $(simple-targets)
$(simple-targets): $(obj)/conf
$< $(silent) --$@ $(Kconfig)
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
PHONY += oldnoconfig savedefconfig defconfig
@@ -108,9 +114,11 @@ else
$(Q)$(MAKE) -f $(srctree)/Makefile $(KBUILD_DEFCONFIG)
endif
endif
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
%_defconfig: $(obj)/conf
$(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@)
@@ -118,6 +126,7 @@ configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/c
$(if $(call configfiles),, $(error No configuration exists for this target on this architecture))
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m .config $(configfiles)
+$(Q)yes "" | $(MAKE) -f $(srctree)/Makefile oldconfig
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
PHONY += kvmconfig
kvmconfig: kvm_guest.config
@@ -130,6 +139,7 @@ xenconfig: xen.config
PHONY += tinyconfig
tinyconfig:
$(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config
+ $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
# Help text used by make help
help:
[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.
Paul.
--
>
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 297c1bf35140..3a0d92040a9c 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -21,18 +21,23 @@ unexport CONFIG_
>
> xconfig: $(obj)/qconf
> $< $(silent) $(Kconfig)
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> gconfig: $(obj)/gconf
> $< $(silent) $(Kconfig)
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> menuconfig: $(obj)/mconf
> $< $(silent) $(Kconfig)
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> config: $(obj)/conf
> $< $(silent) --oldaskconfig $(Kconfig)
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> nconfig: $(obj)/nconf
> $< $(silent) $(Kconfig)
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> silentoldconfig: $(obj)/conf
> $(Q)mkdir -p include/config include/generated
> @@ -85,6 +90,7 @@ PHONY += $(simple-targets)
>
> $(simple-targets): $(obj)/conf
> $< $(silent) --$@ $(Kconfig)
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> PHONY += oldnoconfig savedefconfig defconfig
>
> @@ -108,9 +114,11 @@ else
> $(Q)$(MAKE) -f $(srctree)/Makefile $(KBUILD_DEFCONFIG)
> endif
> endif
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> %_defconfig: $(obj)/conf
> $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@)
>
> @@ -118,6 +126,7 @@ configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/c
> $(if $(call configfiles),, $(error No configuration exists for this target on this architecture))
> $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m .config $(configfiles)
> +$(Q)yes "" | $(MAKE) -f $(srctree)/Makefile oldconfig
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> PHONY += kvmconfig
> kvmconfig: kvm_guest.config
> @@ -130,6 +139,7 @@ xenconfig: xen.config
> PHONY += tinyconfig
> tinyconfig:
> $(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config
> + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>
> # Help text used by make help
> help:
On Fri, Dec 29, 2017 at 01:18:30PM -0500, 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.
>
FWIW just to add another data point, I tripped over this repeatedly
during a recent bisect of v4.14..v4.15-rc4.
My ad-hoc solution was to just delete the stale auto.conf and
reconfigure, IIRC. It was pretty annoying at the time, and I assumed
everyone would be tripping over it so didn't bother making noise on
lkml. Looks like I was mistaken...
Cheers,
Vito Caputo
> > 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.
>
> Paul.
> --
>
> >
> > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> > index 297c1bf35140..3a0d92040a9c 100644
> > --- a/scripts/kconfig/Makefile
> > +++ b/scripts/kconfig/Makefile
> > @@ -21,18 +21,23 @@ unexport CONFIG_
> >
> > xconfig: $(obj)/qconf
> > $< $(silent) $(Kconfig)
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > gconfig: $(obj)/gconf
> > $< $(silent) $(Kconfig)
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > menuconfig: $(obj)/mconf
> > $< $(silent) $(Kconfig)
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > config: $(obj)/conf
> > $< $(silent) --oldaskconfig $(Kconfig)
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > nconfig: $(obj)/nconf
> > $< $(silent) $(Kconfig)
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > silentoldconfig: $(obj)/conf
> > $(Q)mkdir -p include/config include/generated
> > @@ -85,6 +90,7 @@ PHONY += $(simple-targets)
> >
> > $(simple-targets): $(obj)/conf
> > $< $(silent) --$@ $(Kconfig)
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > PHONY += oldnoconfig savedefconfig defconfig
> >
> > @@ -108,9 +114,11 @@ else
> > $(Q)$(MAKE) -f $(srctree)/Makefile $(KBUILD_DEFCONFIG)
> > endif
> > endif
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > %_defconfig: $(obj)/conf
> > $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@)
> >
> > @@ -118,6 +126,7 @@ configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/c
> > $(if $(call configfiles),, $(error No configuration exists for this target on this architecture))
> > $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m .config $(configfiles)
> > +$(Q)yes "" | $(MAKE) -f $(srctree)/Makefile oldconfig
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > PHONY += kvmconfig
> > kvmconfig: kvm_guest.config
> > @@ -130,6 +139,7 @@ xenconfig: xen.config
> > PHONY += tinyconfig
> > tinyconfig:
> > $(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config
> > + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> >
> > # Help text used by make help
> > help:
[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 <[email protected]>
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.
--
On Mon, Dec 17, 2018 at 6:45 AM Paul Gortmaker
<[email protected]> wrote:
>
> [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 <[email protected]>
> 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.
I did not notice this thread
(perhaps, it fell into my crack during the holidays)
but I actually tried to fix this twice in a sophisticated way
in the past.
The first attempt (https://patchwork.kernel.org/patch/10516049/)
was rejected by Josh Poimboeuf.
The second one (https://patchwork.kernel.org/patch/10643245/)
turned out not working as expected.
Now, I am preparing for the third attempt,
but it will take time for review.
What I can do now is the similar fix-up as commit 25896d073d8.
I will post a cheesy fix-up patch.
--
Best Regards
Masahiro Yamada