Mailing List Archive: [PATCH 1/5] x86/build: limit rebuilding of asm-offsets.h

[PATCH 1/5] x86/build: limit rebuilding of asm-offsets.h

Nov 25, 2020, 12:45 AM

Post #1 of 3 (10 views)

This file has a long dependencies list (through asm-offsets.s) and a
long list of dependents. IOW if any of the former changes, all of the
latter will be rebuilt, even if there's no actual change to the
generated file. This is the primary scenario we have the move-if-changed
macro for.

Since debug information may easily cause the file contents to change in
benign ways, also avoid emitting this into the output file.

Finally already before this change *.new files needed including in what
gets removed by the "clean" target.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Perhaps Arm would want doing the same. In fact perhaps the rules should
be unified by moving to common code?

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -235,7 +235,8 @@ efi/buildid.o efi/relocs-dummy.o: $(BASE
efi/buildid.o efi/relocs-dummy.o: ;

asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c $(BASEDIR)/include/asm-x86/asm-macros.h
- $(CC) $(filter-out -Wa$(comma)% -flto,$(c_flags)) -S -o $@ $<
+ $(CC) $(filter-out -Wa$(comma)% -flto,$(c_flags)) -S -g0 -o $@.new $<
+ $(call move-if-changed,$@.new,$@)

asm-macros.i: CFLAGS-y += -D__ASSEMBLY__ -P

@@ -262,7 +263,7 @@ efi/mkreloc: efi/mkreloc.c

.PHONY: clean
clean::
- rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
+ rm -f asm-offsets.s *.lds *.new boot/*.o boot/*~ boot/core boot/mkelf32
rm -f asm-macros.i $(BASEDIR)/include/asm-x86/asm-macros.*
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d $(BASEDIR)/.xen.elf32
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/mkreloc

Re: [PATCH 1/5] x86/build: limit rebuilding of asm-offsets.h [ In reply to ]

roger.pau at citrix

Dec 28, 2020, 4:00 AM

Post #2 of 3 (10 views)

Permalink

On Wed, Nov 25, 2020 at 09:45:56AM +0100, Jan Beulich wrote:
> This file has a long dependencies list (through asm-offsets.s) and a
> long list of dependents. IOW if any of the former changes, all of the
> latter will be rebuilt, even if there's no actual change to the
> generated file. This is the primary scenario we have the move-if-changed
> macro for.
>
> Since debug information may easily cause the file contents to change in
> benign ways, also avoid emitting this into the output file.
>
> Finally already before this change *.new files needed including in what
> gets removed by the "clean" target.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

> ---
> Perhaps Arm would want doing the same. In fact perhaps the rules should
> be unified by moving to common code?

Having the rule in common code would be my preference, the
prerequisites are slightly different, but I think we can sort this
out?

Thanks, Roger.

Re: [PATCH 1/5] x86/build: limit rebuilding of asm-offsets.h [ In reply to ]

jbeulich at suse

Jan 4, 2021, 5:46 AM

Post #3 of 3 (10 views)

Permalink

On 28.12.2020 13:00, Roger Pau Monné wrote:
> On Wed, Nov 25, 2020 at 09:45:56AM +0100, Jan Beulich wrote:
>> This file has a long dependencies list (through asm-offsets.s) and a
>> long list of dependents. IOW if any of the former changes, all of the
>> latter will be rebuilt, even if there's no actual change to the
>> generated file. This is the primary scenario we have the move-if-changed
>> macro for.
>>
>> Since debug information may easily cause the file contents to change in
>> benign ways, also avoid emitting this into the output file.
>>
>> Finally already before this change *.new files needed including in what
>> gets removed by the "clean" target.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

>> ---
>> Perhaps Arm would want doing the same. In fact perhaps the rules should
>> be unified by moving to common code?
>
> Having the rule in common code would be my preference, the
> prerequisites are slightly different, but I think we can sort this
> out?

Well, that's the nice thing about make rules: Dependencies / prereqs
and the actual rule can be specified independently. I.e. I'd envision
per-arch dependency specifications and a common rule (with common
dependencies of course living there as well).

Jan