[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [XEN PATCH for-4.13] xen: Fix race to build arch/x86/efi/relocs-dummy.o



On 15.11.2019 13:12, Anthony PERARD wrote:
> On Fri, Nov 15, 2019 at 11:06:27AM +0100, Jan Beulich wrote:
>> On 14.11.2019 19:05, Anthony PERARD wrote:
>>> With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile
>>> will attempt to build that object. This result in the dependency file
>>> been generated with relocs-dummy.o depending on efi/relocs-dummy.o.
>>
>> I cannot confirm this, what I see is
>>
>> efi/relocs-dummy.o: efi/relocs-dummy.S \
>>  ...
> 
> 
> I've written the commit message base on few evidences, but I don't know
> if the race comes from trying to build $(TARGET).efi. Here is what I
> have:
> 
> # Building Xen with make -j8 after git clean
> make[3]: *** No rule to make target 'efi/relocs-dummy.S', needed by 
> 'relocs-dummy.o'.
> $ head -1 arch/x86/efi/.relocs-dummy.o.d
> relocs-dummy.o: efi/relocs-dummy.S \
> 
> arch/x86/.relocs-dummy.o.d doesn't exist.

So I guess I'd like to include "may" then in that specific sentence of
the commit message, which would be easy enough to do while committing.

> looking back at the make output, relocs-dummy was built with:
> gcc -D__ASSEMBLY__ -m64 -DBUILD_ID -fno-strict-aliasing -Wall 
> -Wstrict-prototypes -Wdeclaration-after-statement 
> -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 
> -fno-omit-frame-pointer -nostdinc -fno-builtin -fno-common -Werror 
> -Wredundant-decls -Wno-pointer-arith -Wvla -pipe -D__XEN__ -include 
> /local/home/sheep/work/xen/xen/include/xen/config.h 
> '-D__OBJECT_FILE__="efi/relocs-dummy.o"' -Wa,--strip-local-absolute -g -MMD 
> -MF efi/.relocs-dummy.o.d -DXEN_BUILD_EFI 
> -I/local/home/sheep/work/xen/xen/include 
> -I/local/home/sheep/work/xen/xen/include/asm-x86/mach-generic 
> -I/local/home/sheep/work/xen/xen/include/asm-x86/mach-default 
> -DXEN_IMG_OFFSET=0x200000 '-D__OBJECT_LABEL__=arch$x86$efi$relocs_dummy.o' 
> -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs 
> -DHAVE_AS_VMX -DHAVE_AS_SSE4_2 -DHAVE_AS_EPT -DHAVE_AS_RDRAND 
> -DHAVE_AS_FSGSBASE -DHAVE_AS_XSAVEOPT -DHAVE_AS_RDSEED -DHAVE_AS_CLWB 
> -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM 
> '-D__OBJECT_LABEL__=arch/x86/efi/relocs-dummy.o' -DHAVE_AS_INVPCID 
> -DHAVE_AS_NEGATIVE_TRUE -DHAVE_AS_NOPS_DIRECTIVE -mno-red-zone -fpic 
> -fno-asynchronous-unwind-tables -mno-sse -mskip-rax-setup 
> -DGCC_HAS_VISIBILITY_ATTRIBUTE -mindirect-branch=thunk-extern 
> -mindirect-branch-register -DCONFIG_INDIRECT_THUNK -fno-jump-tables 
> -mpreferred-stack-boundary=3 -Wa,-I/local/home/sheep/work/xen/xen/include 
> -DBUILD_ID_EFI -c efi/relocs-dummy.S -o efi/relocs-dummy.o
> 
> $ gcc --version
> gcc (GCC) 9.2.0
> 
> I'm guessing that gcc behave differently between both our system?

Quite possible, albeit it's 9.2.0 here too. Different set of patches
on top of the upstream version, I guess.

Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.