Re: [Xen-devel] [PATCH] x86emul: fix test harness and fuzzer build dependencies

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.12.18 at 15:46, <ian.jackson@xxxxxxxxxx> wrote:
> Jan Beulich writes ("[PATCH] x86emul: fix test harness and fuzzer build 
> dependencies"):
>> --- a/tools/fuzz/x86_instruction_emulator/Makefile
>> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
> ...
>> +$(XEN_ROOT)/tools/include/xen/lib/x86/cpuid-autogen.h: FORCE
>> +    $(MAKE) -C $(XEN_ROOT)/tools/include build
> 
> I think this introduces a `make -j' hazard ?  The problem is that this
> branch of the Makefiles tree might enter tools/include while
> another branch is also doing so, resulting in two simultaneous
> executions in the same directory.

What is "another branch" here? So far I was under the impression
that the ability of building x86 emulator fuzzer and test harness
independently is an exception, and that all other parts of the
tools/ subtree are supposed to be built by going through the top
level. Otherwise further dependency issues might arise, due to
top level Makefile's %-tools-public-headers rule.

Hence whether there's a "make -j" hazard here depends on what
that top level rule's purpose is.

>> @@ -27,10 +28,12 @@ ifeq ($(CONFIG_X86),y)
>>      for f in $(filter-out %autogen.h,$(patsubst 
> $(XEN_ROOT)/xen/include/xen/lib/x86/%,%,Makefile $(wildcard 
> $(XEN_ROOT)/xen/include/xen/lib/x86/*.h))); do \
>>              ln -sf $(XEN_ROOT)/xen/include/xen/lib/x86/$$f xen/lib/x86/$$f; 
>> \
>>      done
>> -    $(MAKE) -C xen/lib/x86 all XEN_ROOT=$(XEN_ROOT)
>>  endif
>>      touch $@
>>  
>> +all-$(CONFIG_X86): xen/.dir
>> +    $(MAKE) -C xen/lib/x86 all XEN_ROOT=$(XEN_ROOT)
> 
> And here we have a pre-existing instance of the same bug, I think ?
> 
> With recursive make you can't just
>    $(MAKE) -C .../this
>    $(MAKE) -C .../that
> because of this race problem.  You need to sequence the subdirectories
> correctly in the parent Makefiles so that by the time `here' is
> entered, its dependency directories are already finished.

In general - yes. But with the way the tools/include/ tree gets
populated, I don't think so.

Jan



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