1. Patchew
  2. Xen
  3. [PATCH v3 0/8] xen: beginnings of moving library-like code into an archive
  4. View patch

[PATCH v3 1/8] xen: fix build when $(obj-y) consists of just blanks

Jan Beulich posted 8 patches 5 years, 2 months ago
[PATCH v3 1/8] xen: fix build when $(obj-y) consists of just blanks
Posted by Jan Beulich 5 years, 2 months ago 
This case can occur when combining empty lists

obj-y :=
...
obj-y += $(empty)

or

obj-y := $(empty) $(empty)

where (only) blanks would accumulate. This was only a latent issue until
now, but would become an active issue for Arm once lib/ gets populated
with all respective objects going into the to be introduced lib.a.

Also address a related issue at this occasion: When an empty built_in.o
gets created, .built_in.o.d will have its dependencies recorded. If, on
a subsequent incremental build, an actual constituent of built_in.o
appeared, the $(filter-out ) would leave these recorded dependencies in
place. But of course the linker won't know what to do with C header
files. (The apparent alternative of avoiding to pass $(c_flags) or
$(a_flags) would not be reliable afaict, as among these flags there may
be some affecting information conveyed via the object file to the
linker. The linker, finding inconsistent flags across object files, may
then error out.) Using just $(obj-y) won't work either: It breaks when
the same object file is listed more than once.

Reported-by: Julien Grall <julien@xen.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
 xen/Rules.mk | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 333e19bec343..d5e5eb33de39 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -130,13 +130,13 @@ c_flags += $(CFLAGS-y)
 a_flags += $(CFLAGS-y) $(AFLAGS-y)
 
 built_in.o: $(obj-y) $(extra-y)
-ifeq ($(obj-y),)
+ifeq ($(strip $(obj-y)),)
 	$(CC) $(c_flags) -c -x c /dev/null -o $@
 else
 ifeq ($(CONFIG_LTO),y)
-	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
+	$(LD_LTO) -r -o $@ $(filter $(obj-y),$^)
 else
-	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter $(obj-y),$^)
 endif
 endif
 
@@ -145,10 +145,10 @@ targets += $(filter-out $(subdir-obj-y), $(obj-y)) $(extra-y)
 targets += $(MAKECMDGOALS)
 
 built_in_bin.o: $(obj-bin-y) $(extra-y)
-ifeq ($(obj-bin-y),)
+ifeq ($(strip $(obj-bin-y)),)
 	$(CC) $(a_flags) -c -x assembler /dev/null -o $@
 else
-	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
+	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter $(obj-bin-y),$^)
 endif
 
 # Force execution of pattern rules (for which PHONY cannot be directly used).
-- 
2.22.0
Re: [PATCH v3 1/8] xen: fix build when $(obj-y) consists of just blanks
Posted by Anthony PERARD 5 years, 2 months ago 
On Mon, Nov 23, 2020 at 04:20:52PM +0100, Jan Beulich wrote:
> This case can occur when combining empty lists
> 
> obj-y :=
> ...
> obj-y += $(empty)
> 
> or
> 
> obj-y := $(empty) $(empty)
> 
> where (only) blanks would accumulate. This was only a latent issue until
> now, but would become an active issue for Arm once lib/ gets populated
> with all respective objects going into the to be introduced lib.a.
> 
> Also address a related issue at this occasion: When an empty built_in.o
> gets created, .built_in.o.d will have its dependencies recorded. If, on
> a subsequent incremental build, an actual constituent of built_in.o
> appeared, the $(filter-out ) would leave these recorded dependencies in
> place. But of course the linker won't know what to do with C header
> files. (The apparent alternative of avoiding to pass $(c_flags) or
> $(a_flags) would not be reliable afaict, as among these flags there may
> be some affecting information conveyed via the object file to the
> linker. The linker, finding inconsistent flags across object files, may

How about using $(XEN_CFLAGS) instead of $(c_flags)? That should prevent
CC from generating the .*.o.d files while keeping the relevant flags. I
was planing to do that to avoid the issue, see:
https://lore.kernel.org/xen-devel/20200421161208.2429539-10-anthony.perard@citrix.com

> then error out.) Using just $(obj-y) won't work either: It breaks when
> the same object file is listed more than once.

Do we need to worry about having a object file been listed twice?
Wouldn't that be a mistake?

-- 
Anthony PERARD
Re: [PATCH v3 1/8] xen: fix build when $(obj-y) consists of just blanks
Posted by Jan Beulich 5 years, 2 months ago 
On 09.12.2020 18:40, Anthony PERARD wrote:
> On Mon, Nov 23, 2020 at 04:20:52PM +0100, Jan Beulich wrote:
>> This case can occur when combining empty lists
>>
>> obj-y :=
>> ...
>> obj-y += $(empty)
>>
>> or
>>
>> obj-y := $(empty) $(empty)
>>
>> where (only) blanks would accumulate. This was only a latent issue until
>> now, but would become an active issue for Arm once lib/ gets populated
>> with all respective objects going into the to be introduced lib.a.
>>
>> Also address a related issue at this occasion: When an empty built_in.o
>> gets created, .built_in.o.d will have its dependencies recorded. If, on
>> a subsequent incremental build, an actual constituent of built_in.o
>> appeared, the $(filter-out ) would leave these recorded dependencies in
>> place. But of course the linker won't know what to do with C header
>> files. (The apparent alternative of avoiding to pass $(c_flags) or
>> $(a_flags) would not be reliable afaict, as among these flags there may
>> be some affecting information conveyed via the object file to the
>> linker. The linker, finding inconsistent flags across object files, may
> 
> How about using $(XEN_CFLAGS) instead of $(c_flags)? That should prevent
> CC from generating the .*.o.d files while keeping the relevant flags.

What does "relevant" cover? For an empty .o it may not be important
right now, but I could see

c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_CFLAGS) '-D__OBJECT_FILE__="$@"'
a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_AFLAGS)

include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk

c_flags += $(CFLAGS-y)
a_flags += $(CFLAGS-y) $(AFLAGS-y)

leading to CFLAGS-y / AFLAGS-y which need to be consistent across
_all_ object files (e.g. some recording of ABI used).

> I
> was planing to do that to avoid the issue, see:
> https://lore.kernel.org/xen-devel/20200421161208.2429539-10-anthony.perard@citrix.com
> 
>> then error out.) Using just $(obj-y) won't work either: It breaks when
>> the same object file is listed more than once.
> 
> Do we need to worry about having a object file been listed twice?
> Wouldn't that be a mistake?

No. The list approach (obj-$(CONFIG_xyz) += ...) easily allows for
this to happen. See xen/arch/x86/mm/Makefile for an existing example.

Jan
Re: [PATCH v3 1/8] xen: fix build when $(obj-y) consists of just blanks
Posted by Anthony PERARD 5 years, 2 months ago 
On Thu, Dec 10, 2020 at 11:21:53AM +0100, Jan Beulich wrote:
> On 09.12.2020 18:40, Anthony PERARD wrote:
> > How about using $(XEN_CFLAGS) instead of $(c_flags)? That should prevent
> > CC from generating the .*.o.d files while keeping the relevant flags.
> 
> What does "relevant" cover? For an empty .o it may not be important
> right now, but I could see
> 
> c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_CFLAGS) '-D__OBJECT_FILE__="$@"'
> a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_AFLAGS)
> 
> include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
> 
> c_flags += $(CFLAGS-y)
> a_flags += $(CFLAGS-y) $(AFLAGS-y)
> 
> leading to CFLAGS-y / AFLAGS-y which need to be consistent across
> _all_ object files (e.g. some recording of ABI used).
> 
> > Do we need to worry about having a object file been listed twice?
> > Wouldn't that be a mistake?
> 
> No. The list approach (obj-$(CONFIG_xyz) += ...) easily allows for
> this to happen. See xen/arch/x86/mm/Makefile for an existing example.


Sounds good,
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks,

-- 
Anthony PERARD
Re: [PATCH v3 1/8] xen: fix build when $(obj-y) consists of just blanks
Posted by Bertrand Marquis 5 years, 2 months ago 
Hi Jan,

> On 23 Nov 2020, at 15:20, Jan Beulich <jbeulich@suse.com> wrote:
> 
> This case can occur when combining empty lists
> 
> obj-y :=
> ...
> obj-y += $(empty)
> 
> or
> 
> obj-y := $(empty) $(empty)
> 
> where (only) blanks would accumulate. This was only a latent issue until
> now, but would become an active issue for Arm once lib/ gets populated
> with all respective objects going into the to be introduced lib.a.
> 
> Also address a related issue at this occasion: When an empty built_in.o
> gets created, .built_in.o.d will have its dependencies recorded. If, on
> a subsequent incremental build, an actual constituent of built_in.o
> appeared, the $(filter-out ) would leave these recorded dependencies in
> place. But of course the linker won't know what to do with C header
> files. (The apparent alternative of avoiding to pass $(c_flags) or
> $(a_flags) would not be reliable afaict, as among these flags there may
> be some affecting information conveyed via the object file to the
> linker. The linker, finding inconsistent flags across object files, may
> then error out.) Using just $(obj-y) won't work either: It breaks when
> the same object file is listed more than once.
> 
> Reported-by: Julien Grall <julien@xen.org>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

Cheers
Bertrand

> ---
> xen/Rules.mk | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 333e19bec343..d5e5eb33de39 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -130,13 +130,13 @@ c_flags += $(CFLAGS-y)
> a_flags += $(CFLAGS-y) $(AFLAGS-y)
> 
> built_in.o: $(obj-y) $(extra-y)
> -ifeq ($(obj-y),)
> +ifeq ($(strip $(obj-y)),)
> 	$(CC) $(c_flags) -c -x c /dev/null -o $@
> else
> ifeq ($(CONFIG_LTO),y)
> -	$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
> +	$(LD_LTO) -r -o $@ $(filter $(obj-y),$^)
> else
> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
> +	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter $(obj-y),$^)
> endif
> endif
> 
> @@ -145,10 +145,10 @@ targets += $(filter-out $(subdir-obj-y), $(obj-y)) $(extra-y)
> targets += $(MAKECMDGOALS)
> 
> built_in_bin.o: $(obj-bin-y) $(extra-y)
> -ifeq ($(obj-bin-y),)
> +ifeq ($(strip $(obj-bin-y)),)
> 	$(CC) $(a_flags) -c -x assembler /dev/null -o $@
> else
> -	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
> +	$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter $(obj-bin-y),$^)
> endif
> 
> # Force execution of pattern rules (for which PHONY cannot be directly used).
> -- 
> 2.22.0
> 
> 
>

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.