On 29/08/18 15:00, Jan Beulich wrote: > As was validly pointed out as motivation for similar Linux side changes > (https://lkml.org/lkml/2018/6/22/677), using long sequences of > directives and auxiliary instructions, like is commonly the case when > setting up an alternative patch site, gcc can be mislead into believing > an asm() to be more heavy weight than it really is. By presenting it > with an assembler macro invocation instead, this can be avoided. > > Initially I wanted to outright change the C macros ALTERNATIVE() and > ALTERNATIVE_2() to invoke the respective assembler ones, but doing so > would require quite a bit of cleanup of some use sites, because of the > exra necessary quoting combined with the need that each assembler macro > argument must consist of just a single string literal. We can consider > working towards that subsequently. > > For now, set the stage of using the assembler macros here by providing a > new generated header, being the slightly massaged pre-processor output > of (for now just) alternative-asm.h. The massaging is primarily to be > able to properly track the build dependency: For this, we need the C > compiler to see the inclusion, which means we shouldn't directly use an > asm(". include ...") directive. > > The dependency added to asm-offsets.s is not a true one; it's just the > easiest approach I could think of to make sure the new header gets > generated early on, without having to fiddle with xen/Makefile (and > introducing some x86-specific construct there). > > Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Andrew Cooper <andrew.coop...@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
