diff mbox series

[v3,05/12] kconfig: make syncconfig update .config regardless of sym_change_count

Message ID 1530758389-30862-6-git-send-email-yamada.masahiro@socionext.com
State Superseded
Headers show
Series kbuild/kconfig: do not update config during installation | expand

Commit Message

Masahiro Yamada July 5, 2018, 2:39 a.m. UTC
syncconfig updates the .config only when sym_change_count > 0, i.e.
any change in config symbols has been detected.

Not only symbols but also comments are contained in the .config file.
If only comments are updated, they are not fed back to the .config,
then the stale comments are left-over.  Of course, this is just a
matter of comments, but why not fix it.

I see some scenarios where this happens.

Scenario A:

 1. You have a source tree that has already been configured.

 2. Linus increments the version number in the top-level Makefile
    (i.e. he commits a new release)

 3. You pull it, and run 'make'

 4. syncconfig is invoked because the environment variable,
    KERNELVERSION is updated, but the .config is not updated since
    no config symbol is changed.

 5. The .config file contains a kernel version in the top line:

    # Automatically generated file; DO NOT EDIT.
    # Linux/arm64 4.18.0-rc2 Kernel Configuration

    ... which points to a previous version.

Scenario B:

 1. You have a source tree that has already been configured.

 2. You upgrade the compiler, but it still has the same version number.
    This may happen if you regularly build the latest compiler from
    the source code.

 3. You run 'make'

 4. syncconfig is invoked because the environment variable,
    CC_VERSION_TEXT is updated, but the .config is not updated since
    no config symbol is changed.

 5. The .config file contains the version string of the compiler:

    #
    # Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)
    #

    ... which carries the information of the old compiler.

If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update
the .config file.  Otherwise, it is fine to update it regardless of
sym_change_count.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

---

 scripts/kconfig/conf.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

-- 
2.7.4

Comments

Dirk Gouders July 6, 2018, 12:23 p.m. UTC | #1
Masahiro Yamada <yamada.masahiro@socionext.com> writes:

> syncconfig updates the .config only when sym_change_count > 0, i.e.

> any change in config symbols has been detected.

>

> Not only symbols but also comments are contained in the .config file.

> If only comments are updated, they are not fed back to the .config,

> then the stale comments are left-over.  Of course, this is just a

> matter of comments, but why not fix it.


Hello Masahiro,

I am currently looking at and testing this series.

First: For this patch I would suggest to also edit the syncconfig
       section of "conf --help".

Further, on a slow laptop, I was suspecting, this patch to cause full
rebuilds of everything, each time I ran "make syncconfig" followed by
"make" but could not verify this on another machine, so perhaps I am
just (for testing purposes) removing the wrong files (modules.builtin
for example) -- I am still testing.

But, what irritates me with testing is that (also without your
patches) two consecutive "make" produce different output, one of them
always shows a warning and this is reproducable.  I just want to make
sure there is no other problem that influences my testing:

$ make
  CALL    scripts/checksyscalls.sh
  DESCEND  objtool
  CHK     include/generated/compile.h
  DATAREL arch/x86/boot/compressed/vmlinux
Kernel: arch/x86/boot/bzImage is ready  (#15)
  Building modules, stage 2.
  MODPOST 211 modules

$ make
  CALL    scripts/checksyscalls.sh
  DESCEND  objtool
  CHK     include/generated/compile.h
  LD      arch/x86/boot/compressed/vmlinux
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating a DT_TEXTREL in object.
  ZOFFSET arch/x86/boot/zoffset.h
  AS      arch/x86/boot/header.o
  LD      arch/x86/boot/setup.elf
  OBJCOPY arch/x86/boot/setup.bin
  OBJCOPY arch/x86/boot/vmlinux.bin
  BUILD   arch/x86/boot/bzImage
Setup is 15580 bytes (padded to 15872 bytes).
System is 8069 kB
CRC e01d75ec
Kernel: arch/x86/boot/bzImage is ready  (#15)
  Building modules, stage 2.
  MODPOST 211 modules

Dirk

> I see some scenarios where this happens.

>

> Scenario A:

>

>  1. You have a source tree that has already been configured.

>

>  2. Linus increments the version number in the top-level Makefile

>     (i.e. he commits a new release)

>

>  3. You pull it, and run 'make'

>

>  4. syncconfig is invoked because the environment variable,

>     KERNELVERSION is updated, but the .config is not updated since

>     no config symbol is changed.

>

>  5. The .config file contains a kernel version in the top line:

>

>     # Automatically generated file; DO NOT EDIT.

>     # Linux/arm64 4.18.0-rc2 Kernel Configuration

>

>     ... which points to a previous version.

>

> Scenario B:

>

>  1. You have a source tree that has already been configured.

>

>  2. You upgrade the compiler, but it still has the same version number.

>     This may happen if you regularly build the latest compiler from

>     the source code.

>

>  3. You run 'make'

>

>  4. syncconfig is invoked because the environment variable,

>     CC_VERSION_TEXT is updated, but the .config is not updated since

>     no config symbol is changed.

>

>  5. The .config file contains the version string of the compiler:

>

>     #

>     # Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)

>     #

>

>     ... which carries the information of the old compiler.

>

> If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update

> the .config file.  Otherwise, it is fine to update it regardless of

> sym_change_count.

>

> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

> ---

>

>  scripts/kconfig/conf.c | 10 ++++++----

>  1 file changed, 6 insertions(+), 4 deletions(-)

>

> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c

> index 671ff53..5af8991 100644

> --- a/scripts/kconfig/conf.c

> +++ b/scripts/kconfig/conf.c

> @@ -496,6 +496,7 @@ int main(int ac, char **av)

>  	int opt;

>  	const char *name, *defconfig_file = NULL /* gcc uninit */;

>  	struct stat tmpstat;

> +	int no_conf_write = 0;

>  

>  	tty_stdio = isatty(0) && isatty(1);

>  

> @@ -633,13 +634,14 @@ int main(int ac, char **av)

>  	}

>  

>  	if (sync_kconfig) {

> -		if (conf_get_changed()) {

> -			name = getenv("KCONFIG_NOSILENTUPDATE");

> -			if (name && *name) {

> +		name = getenv("KCONFIG_NOSILENTUPDATE");

> +		if (name && *name) {

> +			if (conf_get_changed()) {

>  				fprintf(stderr,

>  					"\n*** The configuration requires explicit update.\n\n");

>  				return 1;

>  			}

> +			no_conf_write = 1;

>  		}

>  	}

>  

> @@ -688,7 +690,7 @@ int main(int ac, char **av)

>  		/* syncconfig is used during the build so we shall update autoconf.

>  		 * All other commands are only used to generate a config.

>  		 */

> -		if (conf_get_changed() && conf_write(NULL)) {

> +		if (!no_conf_write && conf_write(NULL)) {

>  			fprintf(stderr, "\n*** Error during writing of the configuration.\n\n");

>  			exit(1);

>  		}
Dirk Gouders July 6, 2018, 11:38 p.m. UTC | #2
Dirk Gouders <dirk@gouders.net> writes:

> Masahiro Yamada <yamada.masahiro@socionext.com> writes:

>

>> syncconfig updates the .config only when sym_change_count > 0, i.e.

>> any change in config symbols has been detected.

>>

>> Not only symbols but also comments are contained in the .config file.

>> If only comments are updated, they are not fed back to the .config,

>> then the stale comments are left-over.  Of course, this is just a

>> matter of comments, but why not fix it.

>

> Hello Masahiro,

>

> I am currently looking at and testing this series.

>

> First: For this patch I would suggest to also edit the syncconfig

>        section of "conf --help".

>

> Further, on a slow laptop, I was suspecting, this patch to cause full

> rebuilds of everything, each time I ran "make syncconfig" followed by

> "make" but could not verify this on another machine, so perhaps I am

> just (for testing purposes) removing the wrong files (modules.builtin

> for example) -- I am still testing.

>

> But, what irritates me with testing is that (also without your

> patches) two consecutive "make" produce different output, one of them

> always shows a warning and this is reproducable.  I just want to make

> sure there is no other problem that influences my testing:

>

> $ make

>   CALL    scripts/checksyscalls.sh

>   DESCEND  objtool

>   CHK     include/generated/compile.h

>   DATAREL arch/x86/boot/compressed/vmlinux

> Kernel: arch/x86/boot/bzImage is ready  (#15)

>   Building modules, stage 2.

>   MODPOST 211 modules

>

> $ make

>   CALL    scripts/checksyscalls.sh

>   DESCEND  objtool

>   CHK     include/generated/compile.h

>   LD      arch/x86/boot/compressed/vmlinux

> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'

> ld: warning: creating a DT_TEXTREL in object.

>   ZOFFSET arch/x86/boot/zoffset.h

>   AS      arch/x86/boot/header.o

>   LD      arch/x86/boot/setup.elf

>   OBJCOPY arch/x86/boot/setup.bin

>   OBJCOPY arch/x86/boot/vmlinux.bin

>   BUILD   arch/x86/boot/bzImage

> Setup is 15580 bytes (padded to 15872 bytes).

> System is 8069 kB

> CRC e01d75ec

> Kernel: arch/x86/boot/bzImage is ready  (#15)

>   Building modules, stage 2.

>   MODPOST 211 modules


I spent some more time with the behaviour described above and bisected
to the commit after that two consecutive invocations of "make" (on an
already compiled tree) seem to do different things.  That commit is
98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I
put Kees and Ingo on CC.

I did the bisecting on another system, so I'll provide the output of two
consecutive "make" on an already compiled tree on that machine:

$ make
  CALL    scripts/checksyscalls.sh
  DESCEND  objtool
  CHK     include/generated/compile.h
  DATAREL arch/x86/boot/compressed/vmlinux
Kernel: arch/x86/boot/bzImage is ready  (#48)
  Building modules, stage 2.
  MODPOST 165 modules

$ make
  CALL    scripts/checksyscalls.sh
  DESCEND  objtool
  CHK     include/generated/compile.h
  LD      arch/x86/boot/compressed/vmlinux
  ZOFFSET arch/x86/boot/zoffset.h
  AS      arch/x86/boot/header.o
  LD      arch/x86/boot/setup.elf
  OBJCOPY arch/x86/boot/setup.bin
  OBJCOPY arch/x86/boot/vmlinux.bin
  BUILD   arch/x86/boot/bzImage
Setup is 15644 bytes (padded to 15872 bytes).
System is 6663 kB
CRC 3eb90f40
Kernel: arch/x86/boot/bzImage is ready  (#48)
  Building modules, stage 2.
  MODPOST 165 modules

If I comment out $(call if_changed,check_data_rel) in
arch/x86/boot/compressed/Makefile, two consecutive "make" produce
identical output i.e. seem to not do different things:

$ make
  CALL    scripts/checksyscalls.sh
  DESCEND  objtool
  CHK     include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#49)
  Building modules, stage 2.
  MODPOST 165 modules

$ make
  CALL    scripts/checksyscalls.sh
  DESCEND  objtool
  CHK     include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#49)
  Building modules, stage 2.
  MODPOST 165 modules

So, I guess this different behaviour of two consecutive "make" is not
intentional but I am failing to understand why it happens.

Dirk

>

> Dirk

>

>> I see some scenarios where this happens.

>>

>> Scenario A:

>>

>>  1. You have a source tree that has already been configured.

>>

>>  2. Linus increments the version number in the top-level Makefile

>>     (i.e. he commits a new release)

>>

>>  3. You pull it, and run 'make'

>>

>>  4. syncconfig is invoked because the environment variable,

>>     KERNELVERSION is updated, but the .config is not updated since

>>     no config symbol is changed.

>>

>>  5. The .config file contains a kernel version in the top line:

>>

>>     # Automatically generated file; DO NOT EDIT.

>>     # Linux/arm64 4.18.0-rc2 Kernel Configuration

>>

>>     ... which points to a previous version.

>>

>> Scenario B:

>>

>>  1. You have a source tree that has already been configured.

>>

>>  2. You upgrade the compiler, but it still has the same version number.

>>     This may happen if you regularly build the latest compiler from

>>     the source code.

>>

>>  3. You run 'make'

>>

>>  4. syncconfig is invoked because the environment variable,

>>     CC_VERSION_TEXT is updated, but the .config is not updated since

>>     no config symbol is changed.

>>

>>  5. The .config file contains the version string of the compiler:

>>

>>     #

>>     # Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)

>>     #

>>

>>     ... which carries the information of the old compiler.

>>

>> If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update

>> the .config file.  Otherwise, it is fine to update it regardless of

>> sym_change_count.

>>

>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

>> ---

>>

>>  scripts/kconfig/conf.c | 10 ++++++----

>>  1 file changed, 6 insertions(+), 4 deletions(-)

>>

>> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c

>> index 671ff53..5af8991 100644

>> --- a/scripts/kconfig/conf.c

>> +++ b/scripts/kconfig/conf.c

>> @@ -496,6 +496,7 @@ int main(int ac, char **av)

>>  	int opt;

>>  	const char *name, *defconfig_file = NULL /* gcc uninit */;

>>  	struct stat tmpstat;

>> +	int no_conf_write = 0;

>>  

>>  	tty_stdio = isatty(0) && isatty(1);

>>  

>> @@ -633,13 +634,14 @@ int main(int ac, char **av)

>>  	}

>>  

>>  	if (sync_kconfig) {

>> -		if (conf_get_changed()) {

>> -			name = getenv("KCONFIG_NOSILENTUPDATE");

>> -			if (name && *name) {

>> +		name = getenv("KCONFIG_NOSILENTUPDATE");

>> +		if (name && *name) {

>> +			if (conf_get_changed()) {

>>  				fprintf(stderr,

>>  					"\n*** The configuration requires explicit update.\n\n");

>>  				return 1;

>>  			}

>> +			no_conf_write = 1;

>>  		}

>>  	}

>>  

>> @@ -688,7 +690,7 @@ int main(int ac, char **av)

>>  		/* syncconfig is used during the build so we shall update autoconf.

>>  		 * All other commands are only used to generate a config.

>>  		 */

>> -		if (conf_get_changed() && conf_write(NULL)) {

>> +		if (!no_conf_write && conf_write(NULL)) {

>>  			fprintf(stderr, "\n*** Error during writing of the configuration.\n\n");

>>  			exit(1);

>>  		}
Dirk Gouders July 9, 2018, 11:39 a.m. UTC | #3
Dirk Gouders <dirk@gouders.net> writes:

> Dirk Gouders <dirk@gouders.net> writes:

>

>> Masahiro Yamada <yamada.masahiro@socionext.com> writes:

>>

>>> syncconfig updates the .config only when sym_change_count > 0, i.e.

>>> any change in config symbols has been detected.

>>>

>>> Not only symbols but also comments are contained in the .config file.

>>> If only comments are updated, they are not fed back to the .config,

>>> then the stale comments are left-over.  Of course, this is just a

>>> matter of comments, but why not fix it.

>>

>> Hello Masahiro,

>>

>> I am currently looking at and testing this series.

>>

>> First: For this patch I would suggest to also edit the syncconfig

>>        section of "conf --help".

>>

>> Further, on a slow laptop, I was suspecting, this patch to cause full

>> rebuilds of everything, each time I ran "make syncconfig" followed by

>> "make" but could not verify this on another machine, so perhaps I am

>> just (for testing purposes) removing the wrong files (modules.builtin

>> for example) -- I am still testing.

>>

>> But, what irritates me with testing is that (also without your

>> patches) two consecutive "make" produce different output, one of them

>> always shows a warning and this is reproducable.  I just want to make

>> sure there is no other problem that influences my testing:

>>

>> $ make

>>   CALL    scripts/checksyscalls.sh

>>   DESCEND  objtool

>>   CHK     include/generated/compile.h

>>   DATAREL arch/x86/boot/compressed/vmlinux

>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>   Building modules, stage 2.

>>   MODPOST 211 modules

>>

>> $ make

>>   CALL    scripts/checksyscalls.sh

>>   DESCEND  objtool

>>   CHK     include/generated/compile.h

>>   LD      arch/x86/boot/compressed/vmlinux

>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'

>> ld: warning: creating a DT_TEXTREL in object.

>>   ZOFFSET arch/x86/boot/zoffset.h

>>   AS      arch/x86/boot/header.o

>>   LD      arch/x86/boot/setup.elf

>>   OBJCOPY arch/x86/boot/setup.bin

>>   OBJCOPY arch/x86/boot/vmlinux.bin

>>   BUILD   arch/x86/boot/bzImage

>> Setup is 15580 bytes (padded to 15872 bytes).

>> System is 8069 kB

>> CRC e01d75ec

>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>   Building modules, stage 2.

>>   MODPOST 211 modules

>

> I spent some more time with the behaviour described above and bisected

> to the commit after that two consecutive invocations of "make" (on an

> already compiled tree) seem to do different things.  That commit is

> 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I

> put Kees and Ingo on CC.

>

> I did the bisecting on another system, so I'll provide the output of two

> consecutive "make" on an already compiled tree on that machine:

>

> $ make

>   CALL    scripts/checksyscalls.sh

>   DESCEND  objtool

>   CHK     include/generated/compile.h

>   DATAREL arch/x86/boot/compressed/vmlinux

> Kernel: arch/x86/boot/bzImage is ready  (#48)

>   Building modules, stage 2.

>   MODPOST 165 modules

>

> $ make

>   CALL    scripts/checksyscalls.sh

>   DESCEND  objtool

>   CHK     include/generated/compile.h

>   LD      arch/x86/boot/compressed/vmlinux

>   ZOFFSET arch/x86/boot/zoffset.h

>   AS      arch/x86/boot/header.o

>   LD      arch/x86/boot/setup.elf

>   OBJCOPY arch/x86/boot/setup.bin

>   OBJCOPY arch/x86/boot/vmlinux.bin

>   BUILD   arch/x86/boot/bzImage

> Setup is 15644 bytes (padded to 15872 bytes).

> System is 6663 kB

> CRC 3eb90f40

> Kernel: arch/x86/boot/bzImage is ready  (#48)

>   Building modules, stage 2.

>   MODPOST 165 modules

>

> If I comment out $(call if_changed,check_data_rel) in

> arch/x86/boot/compressed/Makefile, two consecutive "make" produce

> identical output i.e. seem to not do different things:

>

> $ make

>   CALL    scripts/checksyscalls.sh

>   DESCEND  objtool

>   CHK     include/generated/compile.h

> Kernel: arch/x86/boot/bzImage is ready  (#49)

>   Building modules, stage 2.

>   MODPOST 165 modules

>

> $ make

>   CALL    scripts/checksyscalls.sh

>   DESCEND  objtool

>   CHK     include/generated/compile.h

> Kernel: arch/x86/boot/bzImage is ready  (#49)

>   Building modules, stage 2.

>   MODPOST 165 modules

>

> So, I guess this different behaviour of two consecutive "make" is not

> intentional but I am failing to understand why it happens.


I think, I solved the puzzle and perhaps, that saves others some time:

The problem is that "if_changed" was not designed for multiple use
inside a recipe and in the case of compressed/vmlinux, the 2-fold use
created a kind of flip-flop for situations when nothing has to be done
to build the target.

Because each of the two users of "if_changed" stores it's footprint in
.vmlinux.cmd but that file then isn't re-read, one of the two
"if_changed" calculates that nothing has to be done wheras the other one
recognizes a change in the commandline, because it sees the command-line
for the other part of the reciepe.

In the next make, the roles flip, because the previously satisfied
"if_changed" now sees the command-line of the other one.  And so on...

I am not a Kbuild expert but the attached patch fixes that problem by
introducing "if_changed_multi" that accepts two commands -- one whose
commandline should be checked and a second one that should be
executed.

Dirk
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index fa42f895fdde..f39822fca994 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -107,8 +107,8 @@ define cmd_check_data_rel
 endef
 
 $(obj)/vmlinux: $(vmlinux-objs-y) FORCE
-	$(call if_changed,check_data_rel)
-	$(call if_changed,ld)
+	$(call if_changed_multi,ld,check_data_rel)
+	$(call if_changed_multi,ld,ld)
 
 OBJCOPYFLAGS_vmlinux.bin :=  -R .comment -S
 $(obj)/vmlinux.bin: vmlinux FORCE
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index b2d14f1136e8..3bf419319e09 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -265,6 +265,23 @@ if_changed = $(if $(strip $(any-prereq) $(arg-check)),                       \
 	$(echo-cmd) $(cmd_$(1));                                             \
 	printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)
 
+# echo command for command stored in $2
+# Short version is used, if $(quiet) equals `quiet_', otherwise full one.
+echo-cmd2 = $(if $($(quiet)cmd_$(2)),\
+	echo '  $(call escsq,$($(quiet)cmd_$(2)))$(echo-why)';)
+
+# Execute command arg2 if commandline for command arg1 or prerequisite(s) are
+# updated.
+#
+# This is safe for multiple use inside a recipe; arg1 and arg2 may be
+# identical.
+if_changed_multi = $(if $(strip $(any-prereq) $(arg-check)),                \
+	@set -e;                                                             \
+	$(echo-cmd2) : ; \
+	$(cmd_$(2));                                            \
+	printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)
+
+
 # Execute the command and also postprocess generated .d dependencies file.
 if_changed_dep = $(if $(strip $(any-prereq) $(arg-check) ),                  \
 	@set -e;                                                             \
Kees Cook July 10, 2018, 3:19 p.m. UTC | #4
On Mon, Jul 9, 2018 at 4:39 AM, Dirk Gouders <dirk@gouders.net> wrote:
> I think, I solved the puzzle and perhaps, that saves others some time:

>

> The problem is that "if_changed" was not designed for multiple use

> inside a recipe and in the case of compressed/vmlinux, the 2-fold use

> created a kind of flip-flop for situations when nothing has to be done

> to build the target.

>

> Because each of the two users of "if_changed" stores it's footprint in

> .vmlinux.cmd but that file then isn't re-read, one of the two

> "if_changed" calculates that nothing has to be done wheras the other one

> recognizes a change in the commandline, because it sees the command-line

> for the other part of the reciepe.


Ooh, nice find. Thanks for debugging this!

> In the next make, the roles flip, because the previously satisfied

> "if_changed" now sees the command-line of the other one.  And so on...

>

> I am not a Kbuild expert but the attached patch fixes that problem by

> introducing "if_changed_multi" that accepts two commands -- one whose

> commandline should be checked and a second one that should be

> executed.

>

> Dirk

>

>

> diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile

> index fa42f895fdde..f39822fca994 100644

> --- a/arch/x86/boot/compressed/Makefile

> +++ b/arch/x86/boot/compressed/Makefile

> @@ -107,8 +107,8 @@ define cmd_check_data_rel

>  endef

>

>  $(obj)/vmlinux: $(vmlinux-objs-y) FORCE

> -       $(call if_changed,check_data_rel)

> -       $(call if_changed,ld)

> +       $(call if_changed_multi,ld,check_data_rel)

> +       $(call if_changed_multi,ld,ld)


This does seem to do the right thing, but mainly because arg1 is what
actually writes vmlinux, which seems a bit fragile here.

However, the combination is "if_changed" with the "FORCE". This is to
make sure the command line is evaluated in addition to the build deps.
The check_data_rel isn't as sensitive, so maybe the right solution is
just:

-$(obj)/vmlinux: $(vmlinux-objs-y) FORCE
-       $(call if_changed,check_data_rel)
+$(obj)/vmlinux:: $(vmlinux-objs-y)
+       $(call cmd,check_data_rel)
+$(obj)/vmlinux:: $(vmlinux-objs-y) FORCE
        $(call if_changed,ld)

Then check_data_rel is only evaluated with when the deps change (no
FORCE nor if_changed needed), and doesn't interfere with the "ld"
call?

Regardless, the docs for if_changed should be updated to explicitly
mention it should only be called once per target.

-Kees

-- 
Kees Cook
Pixel Security
Masahiro Yamada July 12, 2018, 2:12 a.m. UTC | #5
2018-07-09 20:39 GMT+09:00 Dirk Gouders <dirk@gouders.net>:
> Dirk Gouders <dirk@gouders.net> writes:

>

>> Dirk Gouders <dirk@gouders.net> writes:

>>

>>> Masahiro Yamada <yamada.masahiro@socionext.com> writes:

>>>

>>>> syncconfig updates the .config only when sym_change_count > 0, i.e.

>>>> any change in config symbols has been detected.

>>>>

>>>> Not only symbols but also comments are contained in the .config file.

>>>> If only comments are updated, they are not fed back to the .config,

>>>> then the stale comments are left-over.  Of course, this is just a

>>>> matter of comments, but why not fix it.

>>>

>>> Hello Masahiro,

>>>

>>> I am currently looking at and testing this series.

>>>

>>> First: For this patch I would suggest to also edit the syncconfig

>>>        section of "conf --help".

>>>

>>> Further, on a slow laptop, I was suspecting, this patch to cause full

>>> rebuilds of everything, each time I ran "make syncconfig" followed by

>>> "make" but could not verify this on another machine, so perhaps I am

>>> just (for testing purposes) removing the wrong files (modules.builtin

>>> for example) -- I am still testing.

>>>

>>> But, what irritates me with testing is that (also without your

>>> patches) two consecutive "make" produce different output, one of them

>>> always shows a warning and this is reproducable.  I just want to make

>>> sure there is no other problem that influences my testing:

>>>

>>> $ make

>>>   CALL    scripts/checksyscalls.sh

>>>   DESCEND  objtool

>>>   CHK     include/generated/compile.h

>>>   DATAREL arch/x86/boot/compressed/vmlinux

>>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>>   Building modules, stage 2.

>>>   MODPOST 211 modules

>>>

>>> $ make

>>>   CALL    scripts/checksyscalls.sh

>>>   DESCEND  objtool

>>>   CHK     include/generated/compile.h

>>>   LD      arch/x86/boot/compressed/vmlinux

>>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'

>>> ld: warning: creating a DT_TEXTREL in object.

>>>   ZOFFSET arch/x86/boot/zoffset.h

>>>   AS      arch/x86/boot/header.o

>>>   LD      arch/x86/boot/setup.elf

>>>   OBJCOPY arch/x86/boot/setup.bin

>>>   OBJCOPY arch/x86/boot/vmlinux.bin

>>>   BUILD   arch/x86/boot/bzImage

>>> Setup is 15580 bytes (padded to 15872 bytes).

>>> System is 8069 kB

>>> CRC e01d75ec

>>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>>   Building modules, stage 2.

>>>   MODPOST 211 modules

>>

>> I spent some more time with the behaviour described above and bisected

>> to the commit after that two consecutive invocations of "make" (on an

>> already compiled tree) seem to do different things.  That commit is

>> 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I

>> put Kees and Ingo on CC.

>>

>> I did the bisecting on another system, so I'll provide the output of two

>> consecutive "make" on an already compiled tree on that machine:

>>

>> $ make

>>   CALL    scripts/checksyscalls.sh

>>   DESCEND  objtool

>>   CHK     include/generated/compile.h

>>   DATAREL arch/x86/boot/compressed/vmlinux

>> Kernel: arch/x86/boot/bzImage is ready  (#48)

>>   Building modules, stage 2.

>>   MODPOST 165 modules

>>

>> $ make

>>   CALL    scripts/checksyscalls.sh

>>   DESCEND  objtool

>>   CHK     include/generated/compile.h

>>   LD      arch/x86/boot/compressed/vmlinux

>>   ZOFFSET arch/x86/boot/zoffset.h

>>   AS      arch/x86/boot/header.o

>>   LD      arch/x86/boot/setup.elf

>>   OBJCOPY arch/x86/boot/setup.bin

>>   OBJCOPY arch/x86/boot/vmlinux.bin

>>   BUILD   arch/x86/boot/bzImage

>> Setup is 15644 bytes (padded to 15872 bytes).

>> System is 6663 kB

>> CRC 3eb90f40

>> Kernel: arch/x86/boot/bzImage is ready  (#48)

>>   Building modules, stage 2.

>>   MODPOST 165 modules

>>

>> If I comment out $(call if_changed,check_data_rel) in

>> arch/x86/boot/compressed/Makefile, two consecutive "make" produce

>> identical output i.e. seem to not do different things:

>>

>> $ make

>>   CALL    scripts/checksyscalls.sh

>>   DESCEND  objtool

>>   CHK     include/generated/compile.h

>> Kernel: arch/x86/boot/bzImage is ready  (#49)

>>   Building modules, stage 2.

>>   MODPOST 165 modules

>>

>> $ make

>>   CALL    scripts/checksyscalls.sh

>>   DESCEND  objtool

>>   CHK     include/generated/compile.h

>> Kernel: arch/x86/boot/bzImage is ready  (#49)

>>   Building modules, stage 2.

>>   MODPOST 165 modules

>>

>> So, I guess this different behaviour of two consecutive "make" is not

>> intentional but I am failing to understand why it happens.

>

> I think, I solved the puzzle and perhaps, that saves others some time:

>

> The problem is that "if_changed" was not designed for multiple use

> inside a recipe and in the case of compressed/vmlinux, the 2-fold use

> created a kind of flip-flop for situations when nothing has to be done

> to build the target.

>

> Because each of the two users of "if_changed" stores it's footprint in

> .vmlinux.cmd but that file then isn't re-read, one of the two

> "if_changed" calculates that nothing has to be done wheras the other one

> recognizes a change in the commandline, because it sees the command-line

> for the other part of the reciepe.

>

> In the next make, the roles flip, because the previously satisfied

> "if_changed" now sees the command-line of the other one.  And so on...

>

> I am not a Kbuild expert but the attached patch fixes that problem by

> introducing "if_changed_multi" that accepts two commands -- one whose

> commandline should be checked and a second one that should be

> executed.



if_changed should not appear multiple times in one target.


I think the simplest fix-up is to
create a new command that combines
'cmd_check_data_rel' and 'cmd_ld'.


quiet_cmd_link-vmlinux = LD      $@
      cmd_link-vmlinux = $(cmd_check_data_rel); $(cmd_ld)

$(obj)/vmlinux: $(vmlinux-objs-y) FORCE
        $(call if_changed,link-vmlinux)




Kbuild also supports if_changed_rule,
but the usage is more complex.

There are only a few usages:
https://github.com/torvalds/linux/blob/v4.17/scripts/Makefile.build#L288






> Dirk

>

>

> diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile

> index fa42f895fdde..f39822fca994 100644

> --- a/arch/x86/boot/compressed/Makefile

> +++ b/arch/x86/boot/compressed/Makefile

> @@ -107,8 +107,8 @@ define cmd_check_data_rel

>  endef

>

>  $(obj)/vmlinux: $(vmlinux-objs-y) FORCE

> -       $(call if_changed,check_data_rel)

> -       $(call if_changed,ld)

> +       $(call if_changed_multi,ld,check_data_rel)

> +       $(call if_changed_multi,ld,ld)

>

>  OBJCOPYFLAGS_vmlinux.bin :=  -R .comment -S

>  $(obj)/vmlinux.bin: vmlinux FORCE

> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include

> index b2d14f1136e8..3bf419319e09 100644

> --- a/scripts/Kbuild.include

> +++ b/scripts/Kbuild.include

> @@ -265,6 +265,23 @@ if_changed = $(if $(strip $(any-prereq) $(arg-check)),                       \

>         $(echo-cmd) $(cmd_$(1));                                             \

>         printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)

>

> +# echo command for command stored in $2

> +# Short version is used, if $(quiet) equals `quiet_', otherwise full one.

> +echo-cmd2 = $(if $($(quiet)cmd_$(2)),\

> +       echo '  $(call escsq,$($(quiet)cmd_$(2)))$(echo-why)';)

> +

> +# Execute command arg2 if commandline for command arg1 or prerequisite(s) are

> +# updated.

> +#

> +# This is safe for multiple use inside a recipe; arg1 and arg2 may be

> +# identical.

> +if_changed_multi = $(if $(strip $(any-prereq) $(arg-check)),                \

> +       @set -e;                                                             \

> +       $(echo-cmd2) : ; \

> +       $(cmd_$(2));                                            \

> +       printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)

> +

> +

>  # Execute the command and also postprocess generated .d dependencies file.

>  if_changed_dep = $(if $(strip $(any-prereq) $(arg-check) ),                  \

>         @set -e;                                                             \

>




-- 
Best Regards
Masahiro Yamada
Dirk Gouders July 12, 2018, 11:32 a.m. UTC | #6
Masahiro Yamada <yamada.masahiro@socionext.com> writes:

> 2018-07-09 20:39 GMT+09:00 Dirk Gouders <dirk@gouders.net>:

>> Dirk Gouders <dirk@gouders.net> writes:

>>

>>> Dirk Gouders <dirk@gouders.net> writes:

>>>

>>>> Masahiro Yamada <yamada.masahiro@socionext.com> writes:

>>>>

>>>>> syncconfig updates the .config only when sym_change_count > 0, i.e.

>>>>> any change in config symbols has been detected.

>>>>>

>>>>> Not only symbols but also comments are contained in the .config file.

>>>>> If only comments are updated, they are not fed back to the .config,

>>>>> then the stale comments are left-over.  Of course, this is just a

>>>>> matter of comments, but why not fix it.

>>>>

>>>> Hello Masahiro,

>>>>

>>>> I am currently looking at and testing this series.

>>>>

>>>> First: For this patch I would suggest to also edit the syncconfig

>>>>        section of "conf --help".

>>>>

>>>> Further, on a slow laptop, I was suspecting, this patch to cause full

>>>> rebuilds of everything, each time I ran "make syncconfig" followed by

>>>> "make" but could not verify this on another machine, so perhaps I am

>>>> just (for testing purposes) removing the wrong files (modules.builtin

>>>> for example) -- I am still testing.

>>>>

>>>> But, what irritates me with testing is that (also without your

>>>> patches) two consecutive "make" produce different output, one of them

>>>> always shows a warning and this is reproducable.  I just want to make

>>>> sure there is no other problem that influences my testing:

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>>   DATAREL arch/x86/boot/compressed/vmlinux

>>>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>>>   Building modules, stage 2.

>>>>   MODPOST 211 modules

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>>   LD      arch/x86/boot/compressed/vmlinux

>>>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'

>>>> ld: warning: creating a DT_TEXTREL in object.

>>>>   ZOFFSET arch/x86/boot/zoffset.h

>>>>   AS      arch/x86/boot/header.o

>>>>   LD      arch/x86/boot/setup.elf

>>>>   OBJCOPY arch/x86/boot/setup.bin

>>>>   OBJCOPY arch/x86/boot/vmlinux.bin

>>>>   BUILD   arch/x86/boot/bzImage

>>>> Setup is 15580 bytes (padded to 15872 bytes).

>>>> System is 8069 kB

>>>> CRC e01d75ec

>>>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>>>   Building modules, stage 2.

>>>>   MODPOST 211 modules

>>>

>>> I spent some more time with the behaviour described above and bisected

>>> to the commit after that two consecutive invocations of "make" (on an

>>> already compiled tree) seem to do different things.  That commit is

>>> 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I

>>> put Kees and Ingo on CC.

>>>

>>> I did the bisecting on another system, so I'll provide the output of two

>>> consecutive "make" on an already compiled tree on that machine:

>>>

>>> $ make

>>>   CALL    scripts/checksyscalls.sh

>>>   DESCEND  objtool

>>>   CHK     include/generated/compile.h

>>>   DATAREL arch/x86/boot/compressed/vmlinux

>>> Kernel: arch/x86/boot/bzImage is ready  (#48)

>>>   Building modules, stage 2.

>>>   MODPOST 165 modules

>>>

>>> $ make

>>>   CALL    scripts/checksyscalls.sh

>>>   DESCEND  objtool

>>>   CHK     include/generated/compile.h

>>>   LD      arch/x86/boot/compressed/vmlinux

>>>   ZOFFSET arch/x86/boot/zoffset.h

>>>   AS      arch/x86/boot/header.o

>>>   LD      arch/x86/boot/setup.elf

>>>   OBJCOPY arch/x86/boot/setup.bin

>>>   OBJCOPY arch/x86/boot/vmlinux.bin

>>>   BUILD   arch/x86/boot/bzImage

>>> Setup is 15644 bytes (padded to 15872 bytes).

>>> System is 6663 kB

>>> CRC 3eb90f40

>>> Kernel: arch/x86/boot/bzImage is ready  (#48)

>>>   Building modules, stage 2.

>>>   MODPOST 165 modules

>>>

>>> If I comment out $(call if_changed,check_data_rel) in

>>> arch/x86/boot/compressed/Makefile, two consecutive "make" produce

>>> identical output i.e. seem to not do different things:

>>>

>>> $ make

>>>   CALL    scripts/checksyscalls.sh

>>>   DESCEND  objtool

>>>   CHK     include/generated/compile.h

>>> Kernel: arch/x86/boot/bzImage is ready  (#49)

>>>   Building modules, stage 2.

>>>   MODPOST 165 modules

>>>

>>> $ make

>>>   CALL    scripts/checksyscalls.sh

>>>   DESCEND  objtool

>>>   CHK     include/generated/compile.h

>>> Kernel: arch/x86/boot/bzImage is ready  (#49)

>>>   Building modules, stage 2.

>>>   MODPOST 165 modules

>>>

>>> So, I guess this different behaviour of two consecutive "make" is not

>>> intentional but I am failing to understand why it happens.

>>

>> I think, I solved the puzzle and perhaps, that saves others some time:

>>

>> The problem is that "if_changed" was not designed for multiple use

>> inside a recipe and in the case of compressed/vmlinux, the 2-fold use

>> created a kind of flip-flop for situations when nothing has to be done

>> to build the target.

>>

>> Because each of the two users of "if_changed" stores it's footprint in

>> .vmlinux.cmd but that file then isn't re-read, one of the two

>> "if_changed" calculates that nothing has to be done wheras the other one

>> recognizes a change in the commandline, because it sees the command-line

>> for the other part of the reciepe.

>>

>> In the next make, the roles flip, because the previously satisfied

>> "if_changed" now sees the command-line of the other one.  And so on...

>>

>> I am not a Kbuild expert but the attached patch fixes that problem by

>> introducing "if_changed_multi" that accepts two commands -- one whose

>> commandline should be checked and a second one that should be

>> executed.

>

>

> if_changed should not appear multiple times in one target.

>

> I think the simplest fix-up is to

> create a new command that combines

> 'cmd_check_data_rel' and 'cmd_ld'.

>

>

> quiet_cmd_link-vmlinux = LD      $@

>       cmd_link-vmlinux = $(cmd_check_data_rel); $(cmd_ld)

>

> $(obj)/vmlinux: $(vmlinux-objs-y) FORCE

>         $(call if_changed,link-vmlinux)

>

> Kbuild also supports if_changed_rule,

> but the usage is more complex.

>

> There are only a few usages:

> https://github.com/torvalds/linux/blob/v4.17/scripts/Makefile.build#L288


Just for completeness I will copy in part of a reply from Kees that
shows how double-colon rules can also avoid multiple use of if_changed
for one target:

-$(obj)/vmlinux: $(vmlinux-objs-y) FORCE
-       $(call if_changed,check_data_rel)
+$(obj)/vmlinux:: $(vmlinux-objs-y)
+       $(call cmd,check_data_rel)
+$(obj)/vmlinux:: $(vmlinux-objs-y) FORCE
        $(call if_changed,ld)

The combined command seems to have the advantage that every command to
build the target gets recorded in the .cmd file

A search showed me that we have two more users that use if_changed more
than once for a single target:

          arch/microblaze/boot/Makefile                 (fourfold)
          arch/sparc/boot/Makefile               (2 times twofold)

The sparc case seems to apply to any of the two suggested fixes, but
microblaze uses if_changed in a pattern rule and also makes use of
parameter arguments in the sub-commands:

$(obj)/simpleImage.%: vmlinux FORCE
	$(call if_changed,cp,.unstrip)
	$(call if_changed,objcopy)
	$(call if_changed,uimage)
	$(call if_changed,strip,.strip)
	@echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')'

In this case, double colons would have a different meaning and the
combined command solution would result in a change of the sub-commands,
as well.  I note this in case Michal perhaps has other preferences.


In addition to extend the documentation, we could modify if_changed to
warn about it is being used more than once for a target:

# Execute command if command has changed or prerequisite(s) are updated.
if_changed = $(if $(filter-out undefined,$(origin if_changed_$@)),           \
	@set -e;                                                             \
	echo "Warning: $@: multiple use of if_changed!" >&2; ,               \
	@set -e $(eval if_changed_$@ := 1) ; )                               \
        $(if $(strip $(any-prereq) $(arg-check)),                            \
	$(echo-cmd) $(cmd_$(1));                                             \
	printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, :)

But this fires only if if_changed is actually called and it defines many
variables for just that purpose, so this is perhaps not what we want...

Dirk
Dirk Gouders July 12, 2018, 9:06 p.m. UTC | #7
Dirk Gouders <dirk@gouders.net> writes:

> Masahiro Yamada <yamada.masahiro@socionext.com> writes:

>

>> 2018-07-09 20:39 GMT+09:00 Dirk Gouders <dirk@gouders.net>:

>>> Dirk Gouders <dirk@gouders.net> writes:

>>>

>>>> Dirk Gouders <dirk@gouders.net> writes:

>>>>

>>>>> Masahiro Yamada <yamada.masahiro@socionext.com> writes:

>>>>>

>>>>>> syncconfig updates the .config only when sym_change_count > 0, i.e.

>>>>>> any change in config symbols has been detected.

>>>>>>

>>>>>> Not only symbols but also comments are contained in the .config file.

>>>>>> If only comments are updated, they are not fed back to the .config,

>>>>>> then the stale comments are left-over.  Of course, this is just a

>>>>>> matter of comments, but why not fix it.

>>>>>

>>>>> Hello Masahiro,

>>>>>

>>>>> I am currently looking at and testing this series.

>>>>>

>>>>> First: For this patch I would suggest to also edit the syncconfig

>>>>>        section of "conf --help".

>>>>>

>>>>> Further, on a slow laptop, I was suspecting, this patch to cause full

>>>>> rebuilds of everything, each time I ran "make syncconfig" followed by

>>>>> "make" but could not verify this on another machine, so perhaps I am

>>>>> just (for testing purposes) removing the wrong files (modules.builtin

>>>>> for example) -- I am still testing.

>>>>>

>>>>> But, what irritates me with testing is that (also without your

>>>>> patches) two consecutive "make" produce different output, one of them

>>>>> always shows a warning and this is reproducable.  I just want to make

>>>>> sure there is no other problem that influences my testing:

>>>>>

>>>>> $ make

>>>>>   CALL    scripts/checksyscalls.sh

>>>>>   DESCEND  objtool

>>>>>   CHK     include/generated/compile.h

>>>>>   DATAREL arch/x86/boot/compressed/vmlinux

>>>>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>>>>   Building modules, stage 2.

>>>>>   MODPOST 211 modules

>>>>>

>>>>> $ make

>>>>>   CALL    scripts/checksyscalls.sh

>>>>>   DESCEND  objtool

>>>>>   CHK     include/generated/compile.h

>>>>>   LD      arch/x86/boot/compressed/vmlinux

>>>>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'

>>>>> ld: warning: creating a DT_TEXTREL in object.

>>>>>   ZOFFSET arch/x86/boot/zoffset.h

>>>>>   AS      arch/x86/boot/header.o

>>>>>   LD      arch/x86/boot/setup.elf

>>>>>   OBJCOPY arch/x86/boot/setup.bin

>>>>>   OBJCOPY arch/x86/boot/vmlinux.bin

>>>>>   BUILD   arch/x86/boot/bzImage

>>>>> Setup is 15580 bytes (padded to 15872 bytes).

>>>>> System is 8069 kB

>>>>> CRC e01d75ec

>>>>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>>>>   Building modules, stage 2.

>>>>>   MODPOST 211 modules

>>>>

>>>> I spent some more time with the behaviour described above and bisected

>>>> to the commit after that two consecutive invocations of "make" (on an

>>>> already compiled tree) seem to do different things.  That commit is

>>>> 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I

>>>> put Kees and Ingo on CC.

>>>>

>>>> I did the bisecting on another system, so I'll provide the output of two

>>>> consecutive "make" on an already compiled tree on that machine:

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>>   DATAREL arch/x86/boot/compressed/vmlinux

>>>> Kernel: arch/x86/boot/bzImage is ready  (#48)

>>>>   Building modules, stage 2.

>>>>   MODPOST 165 modules

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>>   LD      arch/x86/boot/compressed/vmlinux

>>>>   ZOFFSET arch/x86/boot/zoffset.h

>>>>   AS      arch/x86/boot/header.o

>>>>   LD      arch/x86/boot/setup.elf

>>>>   OBJCOPY arch/x86/boot/setup.bin

>>>>   OBJCOPY arch/x86/boot/vmlinux.bin

>>>>   BUILD   arch/x86/boot/bzImage

>>>> Setup is 15644 bytes (padded to 15872 bytes).

>>>> System is 6663 kB

>>>> CRC 3eb90f40

>>>> Kernel: arch/x86/boot/bzImage is ready  (#48)

>>>>   Building modules, stage 2.

>>>>   MODPOST 165 modules

>>>>

>>>> If I comment out $(call if_changed,check_data_rel) in

>>>> arch/x86/boot/compressed/Makefile, two consecutive "make" produce

>>>> identical output i.e. seem to not do different things:

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>> Kernel: arch/x86/boot/bzImage is ready  (#49)

>>>>   Building modules, stage 2.

>>>>   MODPOST 165 modules

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>> Kernel: arch/x86/boot/bzImage is ready  (#49)

>>>>   Building modules, stage 2.

>>>>   MODPOST 165 modules

>>>>

>>>> So, I guess this different behaviour of two consecutive "make" is not

>>>> intentional but I am failing to understand why it happens.

>>>

>>> I think, I solved the puzzle and perhaps, that saves others some time:

>>>

>>> The problem is that "if_changed" was not designed for multiple use

>>> inside a recipe and in the case of compressed/vmlinux, the 2-fold use

>>> created a kind of flip-flop for situations when nothing has to be done

>>> to build the target.

>>>

>>> Because each of the two users of "if_changed" stores it's footprint in

>>> .vmlinux.cmd but that file then isn't re-read, one of the two

>>> "if_changed" calculates that nothing has to be done wheras the other one

>>> recognizes a change in the commandline, because it sees the command-line

>>> for the other part of the reciepe.

>>>

>>> In the next make, the roles flip, because the previously satisfied

>>> "if_changed" now sees the command-line of the other one.  And so on...

>>>

>>> I am not a Kbuild expert but the attached patch fixes that problem by

>>> introducing "if_changed_multi" that accepts two commands -- one whose

>>> commandline should be checked and a second one that should be

>>> executed.

>>

>>

>> if_changed should not appear multiple times in one target.

>>

>> I think the simplest fix-up is to

>> create a new command that combines

>> 'cmd_check_data_rel' and 'cmd_ld'.

>>

>>

>> quiet_cmd_link-vmlinux = LD      $@

>>       cmd_link-vmlinux = $(cmd_check_data_rel); $(cmd_ld)

>>

>> $(obj)/vmlinux: $(vmlinux-objs-y) FORCE

>>         $(call if_changed,link-vmlinux)

>>

>> Kbuild also supports if_changed_rule,

>> but the usage is more complex.

>>

>> There are only a few usages:

>> https://github.com/torvalds/linux/blob/v4.17/scripts/Makefile.build#L288

>

> Just for completeness I will copy in part of a reply from Kees that

> shows how double-colon rules can also avoid multiple use of if_changed

> for one target:

>

> -$(obj)/vmlinux: $(vmlinux-objs-y) FORCE

> -       $(call if_changed,check_data_rel)

> +$(obj)/vmlinux:: $(vmlinux-objs-y)

> +       $(call cmd,check_data_rel)

> +$(obj)/vmlinux:: $(vmlinux-objs-y) FORCE

>         $(call if_changed,ld)

>

> The combined command seems to have the advantage that every command to

> build the target gets recorded in the .cmd file

>

> A search showed me that we have two more users that use if_changed more

> than once for a single target:

>

>           arch/microblaze/boot/Makefile                 (fourfold)

>           arch/sparc/boot/Makefile               (2 times twofold)

>

> The sparc case seems to apply to any of the two suggested fixes, but

> microblaze uses if_changed in a pattern rule and also makes use of

> parameter arguments in the sub-commands:

>

> $(obj)/simpleImage.%: vmlinux FORCE

> 	$(call if_changed,cp,.unstrip)

> 	$(call if_changed,objcopy)

> 	$(call if_changed,uimage)

> 	$(call if_changed,strip,.strip)

> 	@echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')'

>

> In this case, double colons would have a different meaning and the

> combined command solution would result in a change of the sub-commands,

> as well.  I note this in case Michal perhaps has other preferences.

>

>

> In addition to extend the documentation, we could modify if_changed to

> warn about it is being used more than once for a target:

>

> # Execute command if command has changed or prerequisite(s) are updated.

> if_changed = $(if $(filter-out undefined,$(origin if_changed_$@)),           \

> 	@set -e;                                                             \

> 	echo "Warning: $@: multiple use of if_changed!" >&2; ,               \

> 	@set -e $(eval if_changed_$@ := 1) ; )                               \

>         $(if $(strip $(any-prereq) $(arg-check)),                            \

> 	$(echo-cmd) $(cmd_$(1));                                             \

> 	printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, :)

>

> But this fires only if if_changed is actually called and it defines many

> variables for just that purpose, so this is perhaps not what we want...


Short addition: it seems, we can use target-specific variables,
reducing the mass of additional valiables to just one
(more correctly: the number of targets created in parallel):

# Execute command if command has changed or prerequisite(s) are updated.
if_changed = $(if $(filter-out undefined,$(origin if_changed_cnt)),          \
	@set -e;                                                             \
	echo "Warning: $@: multiple use of if_changed!" >&2; ,               \
	@set -e $(eval $@: if_changed_cnt := 1) ; )                          \
        $(if $(strip $(any-prereq) $(arg-check)),                            \
	$(echo-cmd) $(cmd_$(1));                                             \
	printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, :)

The documentation for make says that target-specific variables are also
in effect for all prerequisites of this target but as far as I examined
(see attached Makefile and target "check") not for the example above.

In my understanding this is because the variable is created when the
recipe for the target is executed, i.e. all prerequisites are already
done.

I did a "quick" measurement for an allnoconfig configuration on my slow
laptop:

Without additional check:

real    14m45.477s
user    14m10.775s
sys     0m42.997s


With additional check:

real    14m45.562s
user    14m12.045s
sys     0m41.844s

Dirk
-include .check.cmd

comma   := ,
quote   := "
squote  := '
empty   :=
space   := $(empty) $(empty)
space_escape := _-_SPACE_-_
pound := \#

quiet_cmd_a = A
cmd_a = echo "doing a"
quiet_cmd_b = B
cmd_b = echo "doing b"

###
# Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o
dot-target = $(dir $@).$(notdir $@)

###
# Escape single quote for use in echo statements
escsq = $(subst $(squote),'\$(squote)',$1)

ifneq ($(KBUILD_NOCMDDEP),1)
# Check if both arguments are the same including their order. Result is empty
# string if equal. User may override this check using make KBUILD_NOCMDDEP=1
arg-check = $(filter-out $(subst $(space),$(space_escape),$(strip $(cmd_$@))), \
                         $(subst $(space),$(space_escape),$(strip $(cmd_$1))))
else
arg-check = $(if $(strip $(cmd_$@)),,1)
endif

# Replace >$< with >$$< to preserve $ when reloading the .cmd file
# (needed for make)
# Replace >#< with >$(pound)< to avoid starting a comment in the .cmd file
# (needed for make)
# Replace >'< with >'\''< to be able to enclose the whole string in '...'
# (needed for the shell)
make-cmd = $(call escsq,$(subst $(pound),$$(pound),$(subst $$,$$$$,$(cmd_$(1)))))

# Find any prerequisites that is newer than target or that does not exist.
# PHONY targets skipped in both cases.
any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^)

quiet = quiet_
# echo command.
# Short version is used, if $(quiet) equals `quiet_', otherwise full one.
echo-cmd = $(if $($(quiet)cmd_$(1)),\
	echo '  $(call escsq,$($(quiet)cmd_$(1)))$(echo-why)';)

cmd = @$(echo-cmd) $(cmd_$(1))

# Execute command if command has changed or prerequisite(s) are updated.
if_changed = $(if $(filter-out undefined,$(origin if_changed_cnt)),          \
	@set -e;                                                             \
	echo "Warning: $@: multiple use of if_changed!" >&2; ,               \
	@set -e $(eval $@: if_changed_cnt := 1) ; )                          \
        $(if $(strip $(any-prereq) $(arg-check)),                            \
	$(echo-cmd) $(cmd_$(1));                                             \
	printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, :)

PHONY += FORCE
FORCE:

a.o: Makefile
	@printf 'if_change_cnt: -%s-\n' '$(origin if_change_cnt)'
	@touch a.o

check: a.o FORCE
	$(call if_changed,a)
	$(call if_changed,b)
	@touch check
Masahiro Yamada July 13, 2018, 2:57 p.m. UTC | #8
2018-07-12 20:32 GMT+09:00 Dirk Gouders <dirk@gouders.net>:
> Masahiro Yamada <yamada.masahiro@socionext.com> writes:

>

>> 2018-07-09 20:39 GMT+09:00 Dirk Gouders <dirk@gouders.net>:

>>> Dirk Gouders <dirk@gouders.net> writes:

>>>

>>>> Dirk Gouders <dirk@gouders.net> writes:

>>>>

>>>>> Masahiro Yamada <yamada.masahiro@socionext.com> writes:

>>>>>

>>>>>> syncconfig updates the .config only when sym_change_count > 0, i.e.

>>>>>> any change in config symbols has been detected.

>>>>>>

>>>>>> Not only symbols but also comments are contained in the .config file.

>>>>>> If only comments are updated, they are not fed back to the .config,

>>>>>> then the stale comments are left-over.  Of course, this is just a

>>>>>> matter of comments, but why not fix it.

>>>>>

>>>>> Hello Masahiro,

>>>>>

>>>>> I am currently looking at and testing this series.

>>>>>

>>>>> First: For this patch I would suggest to also edit the syncconfig

>>>>>        section of "conf --help".

>>>>>

>>>>> Further, on a slow laptop, I was suspecting, this patch to cause full

>>>>> rebuilds of everything, each time I ran "make syncconfig" followed by

>>>>> "make" but could not verify this on another machine, so perhaps I am

>>>>> just (for testing purposes) removing the wrong files (modules.builtin

>>>>> for example) -- I am still testing.

>>>>>

>>>>> But, what irritates me with testing is that (also without your

>>>>> patches) two consecutive "make" produce different output, one of them

>>>>> always shows a warning and this is reproducable.  I just want to make

>>>>> sure there is no other problem that influences my testing:

>>>>>

>>>>> $ make

>>>>>   CALL    scripts/checksyscalls.sh

>>>>>   DESCEND  objtool

>>>>>   CHK     include/generated/compile.h

>>>>>   DATAREL arch/x86/boot/compressed/vmlinux

>>>>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>>>>   Building modules, stage 2.

>>>>>   MODPOST 211 modules

>>>>>

>>>>> $ make

>>>>>   CALL    scripts/checksyscalls.sh

>>>>>   DESCEND  objtool

>>>>>   CHK     include/generated/compile.h

>>>>>   LD      arch/x86/boot/compressed/vmlinux

>>>>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'

>>>>> ld: warning: creating a DT_TEXTREL in object.

>>>>>   ZOFFSET arch/x86/boot/zoffset.h

>>>>>   AS      arch/x86/boot/header.o

>>>>>   LD      arch/x86/boot/setup.elf

>>>>>   OBJCOPY arch/x86/boot/setup.bin

>>>>>   OBJCOPY arch/x86/boot/vmlinux.bin

>>>>>   BUILD   arch/x86/boot/bzImage

>>>>> Setup is 15580 bytes (padded to 15872 bytes).

>>>>> System is 8069 kB

>>>>> CRC e01d75ec

>>>>> Kernel: arch/x86/boot/bzImage is ready  (#15)

>>>>>   Building modules, stage 2.

>>>>>   MODPOST 211 modules

>>>>

>>>> I spent some more time with the behaviour described above and bisected

>>>> to the commit after that two consecutive invocations of "make" (on an

>>>> already compiled tree) seem to do different things.  That commit is

>>>> 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I

>>>> put Kees and Ingo on CC.

>>>>

>>>> I did the bisecting on another system, so I'll provide the output of two

>>>> consecutive "make" on an already compiled tree on that machine:

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>>   DATAREL arch/x86/boot/compressed/vmlinux

>>>> Kernel: arch/x86/boot/bzImage is ready  (#48)

>>>>   Building modules, stage 2.

>>>>   MODPOST 165 modules

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>>   LD      arch/x86/boot/compressed/vmlinux

>>>>   ZOFFSET arch/x86/boot/zoffset.h

>>>>   AS      arch/x86/boot/header.o

>>>>   LD      arch/x86/boot/setup.elf

>>>>   OBJCOPY arch/x86/boot/setup.bin

>>>>   OBJCOPY arch/x86/boot/vmlinux.bin

>>>>   BUILD   arch/x86/boot/bzImage

>>>> Setup is 15644 bytes (padded to 15872 bytes).

>>>> System is 6663 kB

>>>> CRC 3eb90f40

>>>> Kernel: arch/x86/boot/bzImage is ready  (#48)

>>>>   Building modules, stage 2.

>>>>   MODPOST 165 modules

>>>>

>>>> If I comment out $(call if_changed,check_data_rel) in

>>>> arch/x86/boot/compressed/Makefile, two consecutive "make" produce

>>>> identical output i.e. seem to not do different things:

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>> Kernel: arch/x86/boot/bzImage is ready  (#49)

>>>>   Building modules, stage 2.

>>>>   MODPOST 165 modules

>>>>

>>>> $ make

>>>>   CALL    scripts/checksyscalls.sh

>>>>   DESCEND  objtool

>>>>   CHK     include/generated/compile.h

>>>> Kernel: arch/x86/boot/bzImage is ready  (#49)

>>>>   Building modules, stage 2.

>>>>   MODPOST 165 modules

>>>>

>>>> So, I guess this different behaviour of two consecutive "make" is not

>>>> intentional but I am failing to understand why it happens.

>>>

>>> I think, I solved the puzzle and perhaps, that saves others some time:

>>>

>>> The problem is that "if_changed" was not designed for multiple use

>>> inside a recipe and in the case of compressed/vmlinux, the 2-fold use

>>> created a kind of flip-flop for situations when nothing has to be done

>>> to build the target.

>>>

>>> Because each of the two users of "if_changed" stores it's footprint in

>>> .vmlinux.cmd but that file then isn't re-read, one of the two

>>> "if_changed" calculates that nothing has to be done wheras the other one

>>> recognizes a change in the commandline, because it sees the command-line

>>> for the other part of the reciepe.

>>>

>>> In the next make, the roles flip, because the previously satisfied

>>> "if_changed" now sees the command-line of the other one.  And so on...

>>>

>>> I am not a Kbuild expert but the attached patch fixes that problem by

>>> introducing "if_changed_multi" that accepts two commands -- one whose

>>> commandline should be checked and a second one that should be

>>> executed.

>>

>>

>> if_changed should not appear multiple times in one target.

>>

>> I think the simplest fix-up is to

>> create a new command that combines

>> 'cmd_check_data_rel' and 'cmd_ld'.

>>

>>

>> quiet_cmd_link-vmlinux = LD      $@

>>       cmd_link-vmlinux = $(cmd_check_data_rel); $(cmd_ld)

>>

>> $(obj)/vmlinux: $(vmlinux-objs-y) FORCE

>>         $(call if_changed,link-vmlinux)

>>

>> Kbuild also supports if_changed_rule,

>> but the usage is more complex.

>>

>> There are only a few usages:

>> https://github.com/torvalds/linux/blob/v4.17/scripts/Makefile.build#L288

>

> Just for completeness I will copy in part of a reply from Kees that

> shows how double-colon rules can also avoid multiple use of if_changed

> for one target:

>

> -$(obj)/vmlinux: $(vmlinux-objs-y) FORCE

> -       $(call if_changed,check_data_rel)

> +$(obj)/vmlinux:: $(vmlinux-objs-y)

> +       $(call cmd,check_data_rel)

> +$(obj)/vmlinux:: $(vmlinux-objs-y) FORCE

>         $(call if_changed,ld)


It is difficult to use double-colon rules in a _sane_ way.

The first one just checks data_rel,
but does not actually generate anything.

Such targets should be marked as .PHONY,
but $(obj)/vmlinux is not a phony target.
This is strange.





> The combined command seems to have the advantage that every command to

> build the target gets recorded in the .cmd file

>

> A search showed me that we have two more users that use if_changed more

> than once for a single target:

>

>           arch/microblaze/boot/Makefile                 (fourfold)

>           arch/sparc/boot/Makefile               (2 times twofold)

>

> The sparc case seems to apply to any of the two suggested fixes,


Neither is correct.




$(obj)/uImage: $(obj)/image.gz
        $(call if_changed,uimage)
        $(call if_changed,uimage.o)


should be split into two targets.



$(obj)/uImage: $(obj)/image.gz FORCE
        $(call if_changed,uimage)

$(obj)/uImage.o: $(obj)/uImage FORCE
        $(call if_changed,uimage.o)



It is wrong in multiple ways.  FORCE is missing too.





 but
> microblaze uses if_changed in a pattern rule and also makes use of

> parameter arguments in the sub-commands:

>

> $(obj)/simpleImage.%: vmlinux FORCE

>         $(call if_changed,cp,.unstrip)

>         $(call if_changed,objcopy)

>         $(call if_changed,uimage)

>         $(call if_changed,strip,.strip)

>         @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')'




Probably, this is the same.

Create a target for each step.




> In this case, double colons would have a different meaning and the

> combined command solution would result in a change of the sub-commands,

> as well.  I note this in case Michal perhaps has other preferences.

>

>

> In addition to extend the documentation, we could modify if_changed to

> warn about it is being used more than once for a target:

>

> # Execute command if command has changed or prerequisite(s) are updated.

> if_changed = $(if $(filter-out undefined,$(origin if_changed_$@)),           \

>         @set -e;                                                             \

>         echo "Warning: $@: multiple use of if_changed!" >&2; ,               \

>         @set -e $(eval if_changed_$@ := 1) ; )                               \

>         $(if $(strip $(any-prereq) $(arg-check)),                            \

>         $(echo-cmd) $(cmd_$(1));                                             \

>         printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, :)

>

> But this fires only if if_changed is actually called and it defines many

> variables for just that purpose, so this is perhaps not what we want...

>


I do not want to mess up Makefile.


Please do this check in scripts/checkpatch.pl
if you want.


-- 
Best Regards
Masahiro Yamada
Dirk Gouders July 14, 2018, 7:12 a.m. UTC | #9
Masahiro Yamada <yamada.masahiro@socionext.com> writes:

> 2018-07-12 20:32 GMT+09:00 Dirk Gouders <dirk@gouders.net>:

>> Masahiro Yamada <yamada.masahiro@socionext.com> writes:

>>

>>> 2018-07-09 20:39 GMT+09:00 Dirk Gouders <dirk@gouders.net>:

>>>> Dirk Gouders <dirk@gouders.net> writes:

>>>>

>>>> I think, I solved the puzzle and perhaps, that saves others some time:

>>>>

>>>> The problem is that "if_changed" was not designed for multiple use

>>>> inside a recipe and in the case of compressed/vmlinux, the 2-fold use

>>>> created a kind of flip-flop for situations when nothing has to be done

>>>> to build the target.

>>>>

>>>> Because each of the two users of "if_changed" stores it's footprint in

>>>> .vmlinux.cmd but that file then isn't re-read, one of the two

>>>> "if_changed" calculates that nothing has to be done wheras the other one

>>>> recognizes a change in the commandline, because it sees the command-line

>>>> for the other part of the reciepe.

>>>>

>>>> In the next make, the roles flip, because the previously satisfied

>>>> "if_changed" now sees the command-line of the other one.  And so on...

>>>>

>>>> I am not a Kbuild expert but the attached patch fixes that problem by

>>>> introducing "if_changed_multi" that accepts two commands -- one whose

>>>> commandline should be checked and a second one that should be

>>>> executed.

>>>

>>>

>>> if_changed should not appear multiple times in one target.

>>>

>>> I think the simplest fix-up is to

>>> create a new command that combines

>>> 'cmd_check_data_rel' and 'cmd_ld'.

>>>

>>>

>>> quiet_cmd_link-vmlinux = LD      $@

>>>       cmd_link-vmlinux = $(cmd_check_data_rel); $(cmd_ld)

>>>

>>> $(obj)/vmlinux: $(vmlinux-objs-y) FORCE

>>>         $(call if_changed,link-vmlinux)

>>>

>>> Kbuild also supports if_changed_rule,

>>> but the usage is more complex.

>>>

>>> There are only a few usages:

>>> https://github.com/torvalds/linux/blob/v4.17/scripts/Makefile.build#L288

>>

>> Just for completeness I will copy in part of a reply from Kees that

>> shows how double-colon rules can also avoid multiple use of if_changed

>> for one target:

>>

>> -$(obj)/vmlinux: $(vmlinux-objs-y) FORCE

>> -       $(call if_changed,check_data_rel)

>> +$(obj)/vmlinux:: $(vmlinux-objs-y)

>> +       $(call cmd,check_data_rel)

>> +$(obj)/vmlinux:: $(vmlinux-objs-y) FORCE

>>         $(call if_changed,ld)

>

> It is difficult to use double-colon rules in a _sane_ way.

>

> The first one just checks data_rel,

> but does not actually generate anything.

>

> Such targets should be marked as .PHONY,

> but $(obj)/vmlinux is not a phony target.

> This is strange.

>

>> The combined command seems to have the advantage that every command to

>> build the target gets recorded in the .cmd file

>>

>> A search showed me that we have two more users that use if_changed more

>> than once for a single target:

>>

>>           arch/microblaze/boot/Makefile                 (fourfold)

>>           arch/sparc/boot/Makefile               (2 times twofold)

>>

>> The sparc case seems to apply to any of the two suggested fixes,

>

> Neither is correct.

>

>

> $(obj)/uImage: $(obj)/image.gz

>         $(call if_changed,uimage)

>         $(call if_changed,uimage.o)

>

>

> should be split into two targets.

>

>

> $(obj)/uImage: $(obj)/image.gz FORCE

>         $(call if_changed,uimage)

>

> $(obj)/uImage.o: $(obj)/uImage FORCE

>         $(call if_changed,uimage.o)

>

>

> It is wrong in multiple ways.  FORCE is missing too.

>

>  but

>> microblaze uses if_changed in a pattern rule and also makes use of

>> parameter arguments in the sub-commands:

>>

>> $(obj)/simpleImage.%: vmlinux FORCE

>>         $(call if_changed,cp,.unstrip)

>>         $(call if_changed,objcopy)

>>         $(call if_changed,uimage)

>>         $(call if_changed,strip,.strip)

>>         @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')'

>

>

> Probably, this is the same.

>

> Create a target for each step.

>

>

>> In this case, double colons would have a different meaning and the

>> combined command solution would result in a change of the sub-commands,

>> as well.  I note this in case Michal perhaps has other preferences.

>>

>>

>> In addition to extend the documentation, we could modify if_changed to

>> warn about it is being used more than once for a target:

>>

>> # Execute command if command has changed or prerequisite(s) are updated.

>> if_changed = $(if $(filter-out undefined,$(origin if_changed_$@)),           \

>>         @set -e;                                                             \

>>         echo "Warning: $@: multiple use of if_changed!" >&2; ,               \

>>         @set -e $(eval if_changed_$@ := 1) ; )                               \

>>         $(if $(strip $(any-prereq) $(arg-check)),                            \

>>         $(echo-cmd) $(cmd_$(1));                                             \

>>         printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, :)

>>

>> But this fires only if if_changed is actually called and it defines many

>> variables for just that purpose, so this is perhaps not what we want...

>>

>

> I do not want to mess up Makefile.

>

>

> Please do this check in scripts/checkpatch.pl

> if you want.


Thank you for spending your time in the detailed explanation.
I will use it to assemble that all to a fix and then send it for review.

Dirk
diff mbox series

Patch

diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 671ff53..5af8991 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -496,6 +496,7 @@  int main(int ac, char **av)
 	int opt;
 	const char *name, *defconfig_file = NULL /* gcc uninit */;
 	struct stat tmpstat;
+	int no_conf_write = 0;
 
 	tty_stdio = isatty(0) && isatty(1);
 
@@ -633,13 +634,14 @@  int main(int ac, char **av)
 	}
 
 	if (sync_kconfig) {
-		if (conf_get_changed()) {
-			name = getenv("KCONFIG_NOSILENTUPDATE");
-			if (name && *name) {
+		name = getenv("KCONFIG_NOSILENTUPDATE");
+		if (name && *name) {
+			if (conf_get_changed()) {
 				fprintf(stderr,
 					"\n*** The configuration requires explicit update.\n\n");
 				return 1;
 			}
+			no_conf_write = 1;
 		}
 	}
 
@@ -688,7 +690,7 @@  int main(int ac, char **av)
 		/* syncconfig is used during the build so we shall update autoconf.
 		 * All other commands are only used to generate a config.
 		 */
-		if (conf_get_changed() && conf_write(NULL)) {
+		if (!no_conf_write && conf_write(NULL)) {
 			fprintf(stderr, "\n*** Error during writing of the configuration.\n\n");
 			exit(1);
 		}