On Tue, Sep 21, 2021 at 05:43:38PM +0200, Jan Beulich wrote: > The xen-syms and xen.efi linking steps are serialized only when the > intermediate note.o file is necessary. Otherwise both may run in > parallel. This in turn means that the compiler / linker invocations to > create efi/check.o / efi/check.efi may also happen twice in parallel. > Obviously it's a bad idea to have multiple producers of the same output > race with one another - every once in a while one may e.g. observe > > objdump: efi/check.efi: file format not recognized > > We don't need this EFI related checking to occur when producing the > intermediate symbol and relocation table objects, and we have an easy > way of suppressing it: Simply pass in "efi-y=", overriding the > assignments done in the Makefile and thus forcing the tool chain checks > to be bypassed. > > Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Anthony PERARD <[email protected]> > --- > Obviously the real (but more involved) solution would be to do away with > the recursive $(MAKE) invocations, by breaking up the long linking > rules. Representing them instead through multiple smaller rules with > suitable dependencies is certainly possible (and might even reduce > redundancy). There is an alternative to that. Linux have a script which does the kind of step we do. So maybe doing the same and move the recipe into a script would work too? This would allow to share the recipe between x86 and Arm as the link phase of xen-syms is nearly identical. But to avoid calling make from the script we would have to duplicate the recipe of %.o:%.S. The xen.efi rules is still x86 only and I don't know whether we could use the same script as for xen-syms. I don't know which option would be better those two and the current state. Cheers, -- Anthony PERARD
