From: Anthony PERARD <anthony.perard@gmail.com>
We would like to calculate CFLAGS once and before calling Rules.mk,
so the variable CFLAGS needs to have the same value across the whole
build. Thus we need a new variable where some flags can change
depending on the target name.
Both the dependency and __OBJECT_FILE__ are such flags that change
depending on the target, so there are move out of $(CFLAGS).
__OBJECT_FILE__ is only used by arch/x86/mm/*.c files, so having it in
$(c_flags) is enough, we don't need it in $(a_flags).
This is inspired by the way Kbuild generates CFLAGS for each targets.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
xen/Rules.mk | 27 +++++++++++++++------------
xen/arch/arm/Makefile | 4 ++--
xen/arch/x86/Makefile | 6 +++---
xen/arch/x86/mm/Makefile | 6 +++---
xen/arch/x86/mm/hap/Makefile | 6 +++---
xen/arch/x86/mm/shadow/Makefile | 6 +++---
xen/include/Makefile | 2 +-
7 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index d20521cc9ec1..c98d5372f3db 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -57,7 +57,6 @@ CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
$(call cc-option-add,CFLAGS,CC,-Wvla)
CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
CFLAGS-$(CONFIG_DEBUG_INFO) += -g
-CFLAGS += '-D__OBJECT_FILE__="$@"'
ifneq ($(CONFIG_CC_IS_CLANG),y)
# Clang doesn't understand this command line argument, and doesn't appear to
@@ -70,9 +69,6 @@ AFLAGS-y += -D__ASSEMBLY__
ALL_OBJS := $(ALL_OBJS-y)
-# Get gcc to generate the dependencies for us.
-CFLAGS-y += -MMD -MF $(@D)/.$(@F).d
-
CFLAGS += $(CFLAGS-y)
# allow extra CFLAGS externally via EXTRA_CFLAGS_XEN_CORE
CFLAGS += $(EXTRA_CFLAGS_XEN_CORE)
@@ -141,9 +137,16 @@ endif
# Always build obj-bin files as binary even if they come from C source.
$(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
+c_flags = -MMD -MF $(@D)/.$(@F).d \
+ $(CFLAGS) \
+ '-D__OBJECT_FILE__="$@"'
+
+a_flags = -MMD -MF $(@D)/.$(@F).d \
+ $(AFLAGS)
+
built_in.o: $(obj-y) $(extra-y)
ifeq ($(obj-y),)
- $(CC) $(CFLAGS) -c -x c /dev/null -o $@
+ $(CC) $(c_flags) -c -x c /dev/null -o $@
else
ifeq ($(CONFIG_LTO),y)
$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
@@ -154,7 +157,7 @@ endif
built_in_bin.o: $(obj-bin-y) $(extra-y)
ifeq ($(obj-bin-y),)
- $(CC) $(AFLAGS) -c -x assembler /dev/null -o $@
+ $(CC) $(a_flags) -c -x assembler /dev/null -o $@
else
$(LD) $(LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
endif
@@ -173,7 +176,7 @@ SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR))
%.o: %.c Makefile
ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y)
- $(CC) $(CFLAGS) -c $< -o $(@D)/.$(@F).tmp
+ $(CC) $(c_flags) -c $< -o $(@D)/.$(@F).tmp
ifeq ($(CONFIG_CC_IS_CLANG),y)
$(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< $(@D)/.$(@F).tmp $@
else
@@ -181,11 +184,11 @@ else
endif
rm -f $(@D)/.$(@F).tmp
else
- $(CC) $(CFLAGS) -c $< -o $@
+ $(CC) $(c_flags) -c $< -o $@
endif
%.o: %.S Makefile
- $(CC) $(AFLAGS) -c $< -o $@
+ $(CC) $(a_flags) -c $< -o $@
SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
$(foreach w,1 2 4, \
@@ -206,13 +209,13 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
$(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
%.i: %.c Makefile
- $(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) $< -o $@
+ $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
%.s: %.c Makefile
- $(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -S $< -o $@
+ $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
# -std=gnu{89,99} gets confused by # as an end-of-line comment marker
%.s: %.S Makefile
- $(CPP) $(filter-out -Wa$(comma)%,$(AFLAGS)) $< -o $@
+ $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
-include $(DEPS_INCLUDE)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1044c2298a05..7f1427630b96 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -121,10 +121,10 @@ $(TARGET)-syms: prelink.o xen.lds
rm -f $(@D)/.$(@F).[0-9]*
asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
- $(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
+ $(CC) $(filter-out -flto,$(c_flags)) -S -o $@ $<
xen.lds: xen.lds.S
- $(CC) -P -E -Ui386 $(AFLAGS) -o $@ $<
+ $(CC) -P -E -Ui386 $(a_flags) -o $@ $<
sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
mv -f .xen.lds.d.new .xen.lds.d
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 461d1f3dc2a6..472e3fadb719 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -225,7 +225,7 @@ efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o efi/relocs-dummy.o: $(B
efi/boot.init.o efi/runtime.o efi/compat.o 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,$(CFLAGS)) -S -o $@ $<
+ $(CC) $(filter-out -Wa$(comma)% -flto,$(c_flags)) -S -o $@ $<
asm-macros.i: CFLAGS += -D__ASSEMBLY__ -P
@@ -241,12 +241,12 @@ $(BASEDIR)/include/asm-x86/asm-macros.h: asm-macros.i Makefile
$(call move-if-changed,$@.new,$@)
xen.lds: xen.lds.S
- $(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
+ $(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<
sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new
mv -f .$(@F).d.new .$(@F).d
efi.lds: xen.lds.S
- $(CC) -P -E -Ui386 -DEFI $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
+ $(CC) -P -E -Ui386 -DEFI $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<
sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new
mv -f .$(@F).d.new .$(@F).d
diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index d87dc0aa6eeb..a2431fde6bb4 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -12,10 +12,10 @@ obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
obj-y += paging.o
guest_walk_%.o: guest_walk.c Makefile
- $(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+ $(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
guest_walk_%.i: guest_walk.c Makefile
- $(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+ $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
guest_walk_%.s: guest_walk.c Makefile
- $(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
+ $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
diff --git a/xen/arch/x86/mm/hap/Makefile b/xen/arch/x86/mm/hap/Makefile
index b14a9aff93d2..22e7ad54bd33 100644
--- a/xen/arch/x86/mm/hap/Makefile
+++ b/xen/arch/x86/mm/hap/Makefile
@@ -6,10 +6,10 @@ obj-y += nested_hap.o
obj-y += nested_ept.o
guest_walk_%level.o: guest_walk.c Makefile
- $(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+ $(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
guest_walk_%level.i: guest_walk.c Makefile
- $(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+ $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
guest_walk_%level.s: guest_walk.c Makefile
- $(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
+ $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
diff --git a/xen/arch/x86/mm/shadow/Makefile b/xen/arch/x86/mm/shadow/Makefile
index ff03a9937f9b..23d3ff10802c 100644
--- a/xen/arch/x86/mm/shadow/Makefile
+++ b/xen/arch/x86/mm/shadow/Makefile
@@ -7,10 +7,10 @@ obj-y += none.o
endif
guest_%.o: multi.c Makefile
- $(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+ $(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
guest_%.i: multi.c Makefile
- $(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+ $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
guest_%.s: multi.c Makefile
- $(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
+ $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 433bad9055b2..83131c2472f5 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -64,7 +64,7 @@ compat/%.h: compat/%.i Makefile $(BASEDIR)/tools/compat-build-header.py
mv -f $@.new $@
compat/%.i: compat/%.c Makefile
- $(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $<
+ $(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(c_flags)) $(cppflags-y) -o $@ $<
compat/%.c: public/%.h xlat.lst Makefile $(BASEDIR)/tools/compat-build-source.py
mkdir -p $(@D)
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-develOn 17.01.2020 11:53, Anthony PERARD wrote: > We would like to calculate CFLAGS once and before calling Rules.mk, > so the variable CFLAGS needs to have the same value across the whole > build. Thus we need a new variable where some flags can change > depending on the target name. > > Both the dependency and __OBJECT_FILE__ are such flags that change > depending on the target, so there are move out of $(CFLAGS). I'm afraid I don't understand: Being a delayed expansion (or "recursively expanded") variable, what problem is there when CFLAGS references $@? Is there a plan to change the variable's flavor? If so, I'd like to ask for this to be mentioned here. "Calculate once", at least to me, doesn't imply this. > @@ -141,9 +137,16 @@ endif > # Always build obj-bin files as binary even if they come from C source. > $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS)) > > +c_flags = -MMD -MF $(@D)/.$(@F).d \ > + $(CFLAGS) \ > + '-D__OBJECT_FILE__="$@"' > + > +a_flags = -MMD -MF $(@D)/.$(@F).d \ > + $(AFLAGS) Is there a reason both get extended over multiple lines? > --- a/xen/include/Makefile > +++ b/xen/include/Makefile > @@ -64,7 +64,7 @@ compat/%.h: compat/%.i Makefile $(BASEDIR)/tools/compat-build-header.py > mv -f $@.new $@ > > compat/%.i: compat/%.c Makefile > - $(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $< > + $(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(c_flags)) $(cppflags-y) -o $@ $< I think this wants to continue to reference $(CFLAGS) and instead have the -M% and %.d patterns dropped. Similarly I guess as-insn in Config.mk could then have these two patterns dropped. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
On Thu, Jan 30, 2020 at 02:29:42PM +0100, Jan Beulich wrote:
> On 17.01.2020 11:53, Anthony PERARD wrote:
> > We would like to calculate CFLAGS once and before calling Rules.mk,
> > so the variable CFLAGS needs to have the same value across the whole
> > build. Thus we need a new variable where some flags can change
> > depending on the target name.
> >
> > Both the dependency and __OBJECT_FILE__ are such flags that change
> > depending on the target, so there are move out of $(CFLAGS).
>
> I'm afraid I don't understand: Being a delayed expansion (or
> "recursively expanded") variable, what problem is there when CFLAGS
> references $@? Is there a plan to change the variable's flavor? If
> so, I'd like to ask for this to be mentioned here. "Calculate once",
> at least to me, doesn't imply this.
If I rewrite the first paragraph thus, would that be better?
In a later patch, we want to calculate the CFLAGS in xen/Makefile,
then export it. So have Rules.mk use a CFLAGS from the environment
variables. This will mean that if Rules.mk or a Makefile modify
CFLAGS for a target, the modification propagates to other targets.
Thus we will need a different variable name than the one from the
environment which can have a different value for each target.
> > @@ -141,9 +137,16 @@ endif
> > # Always build obj-bin files as binary even if they come from C source.
> > $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
> >
> > +c_flags = -MMD -MF $(@D)/.$(@F).d \
> > + $(CFLAGS) \
> > + '-D__OBJECT_FILE__="$@"'
> > +
> > +a_flags = -MMD -MF $(@D)/.$(@F).d \
> > + $(AFLAGS)
>
> Is there a reason both get extended over multiple lines?
Beside that it looks cleaner to me, not really.
> > --- a/xen/include/Makefile
> > +++ b/xen/include/Makefile
> > @@ -64,7 +64,7 @@ compat/%.h: compat/%.i Makefile $(BASEDIR)/tools/compat-build-header.py
> > mv -f $@.new $@
> >
> > compat/%.i: compat/%.c Makefile
> > - $(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $<
> > + $(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(c_flags)) $(cppflags-y) -o $@ $<
>
> I think this wants to continue to reference $(CFLAGS) and instead have
> the -M% and %.d patterns dropped. Similarly I guess as-insn in Config.mk
> could then have these two patterns dropped.
It's probably a good idea to keep using CFLAGS, I'll look into it.
As to change as-insn, I can move it out of Config.mk and then change it.
I'll look into that as well.
Thanks,
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 03.02.2020 13:17, Anthony PERARD wrote: > On Thu, Jan 30, 2020 at 02:29:42PM +0100, Jan Beulich wrote: >> On 17.01.2020 11:53, Anthony PERARD wrote: >>> We would like to calculate CFLAGS once and before calling Rules.mk, >>> so the variable CFLAGS needs to have the same value across the whole >>> build. Thus we need a new variable where some flags can change >>> depending on the target name. >>> >>> Both the dependency and __OBJECT_FILE__ are such flags that change >>> depending on the target, so there are move out of $(CFLAGS). >> >> I'm afraid I don't understand: Being a delayed expansion (or >> "recursively expanded") variable, what problem is there when CFLAGS >> references $@? Is there a plan to change the variable's flavor? If >> so, I'd like to ask for this to be mentioned here. "Calculate once", >> at least to me, doesn't imply this. > > If I rewrite the first paragraph thus, would that be better? > > In a later patch, we want to calculate the CFLAGS in xen/Makefile, > then export it. So have Rules.mk use a CFLAGS from the environment > variables. This will mean that if Rules.mk or a Makefile modify > CFLAGS for a target, the modification propagates to other targets. > Thus we will need a different variable name than the one from the > environment which can have a different value for each target. I think this is better, yes, albeit I'm still a little unhappy about the uses of "target" here: It makes it look to me as if this was primarily about things like abc.o: CFLAGS += ... where, unless its rule invokes make, I don't think the adjustment would propagate anywhere. Instead aiui what you refer to is solely an effect from the subdir traversal the build system does? >>> @@ -141,9 +137,16 @@ endif >>> # Always build obj-bin files as binary even if they come from C source. >>> $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS)) >>> >>> +c_flags = -MMD -MF $(@D)/.$(@F).d \ >>> + $(CFLAGS) \ >>> + '-D__OBJECT_FILE__="$@"' >>> + >>> +a_flags = -MMD -MF $(@D)/.$(@F).d \ >>> + $(AFLAGS) >> >> Is there a reason both get extended over multiple lines? > > Beside that it looks cleaner to me, not really. Apparently a matter of taste then. I generally consider trailing backslashes a little "unclean", and hence would prefer to avoid them if I can. >>> --- a/xen/include/Makefile >>> +++ b/xen/include/Makefile >>> @@ -64,7 +64,7 @@ compat/%.h: compat/%.i Makefile $(BASEDIR)/tools/compat-build-header.py >>> mv -f $@.new $@ >>> >>> compat/%.i: compat/%.c Makefile >>> - $(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $< >>> + $(CPP) $(filter-out -Wa$(comma)% -M% %.d -include %/include/xen/config.h,$(c_flags)) $(cppflags-y) -o $@ $< >> >> I think this wants to continue to reference $(CFLAGS) and instead have >> the -M% and %.d patterns dropped. Similarly I guess as-insn in Config.mk >> could then have these two patterns dropped. > > It's probably a good idea to keep using CFLAGS, I'll look into it. > As to change as-insn, I can move it out of Config.mk and then change it. > I'll look into that as well. Thank you. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
© 2016 - 2026 Red Hat, Inc.