Re: [Xen-devel] [PATCH 1/2] x86/clang: fix build with indirect thunks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.01.18 at 16:48, <roger.pau@xxxxxxxxxx> wrote:
> The build with clang is currently broken because clang requires asm
> macros to be declared inside the same inline asm declaration where
> they are used.

I don't understand this: What if I have two asm()-s needing it? Does
this need to be done in each one? I'd expect this to result in duplicate
definitions on gas then (which may or may not be benign).

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -66,8 +66,10 @@ endif
>  
>  AFLAGS-y                += -D__ASSEMBLY__
>  
> -# Clang's built-in assembler can't handle embedded .include's
> -CFLAGS-$(clang)         += -no-integrated-as
> +# Clang's built-in assembler doesn't understand assembler directives without
> +# an absolute value:
> +# https://bugs.llvm.org/show_bug.cgi?id=27369 
> +AFLAGS-$(clang)         += -no-integrated-as

I also don't understand this - when you switch (back) to AFLAGS, you
don't affect C files. Furthermore without using its integrated assembler
for C files at present - how is the build broken? Is the description of
the change perhaps in need of some re-work (and maybe the title as
well)?

Nor am I of the opinion that the comment above is really correct -
I'm sure there are directives where their assembler supports non-
constant values (.include being the obvious first case in the context
here).

And finally, if you switch back to use AFLAGS here, you should
either restore the original comment as well, or explain in the
description why it isn't applicable anymore.

> --- a/xen/arch/x86/extable.c
> +++ b/xen/arch/x86/extable.c
> @@ -158,7 +158,8 @@ static int __init stub_selftest(void)
>          memcpy(ptr, tests[i].opc, ARRAY_SIZE(tests[i].opc));
>          unmap_domain_page(ptr);
>  
> -        asm volatile ( "INDIRECT_CALL %[stb]\n"
> +        asm volatile ( INCLUDE_INDIRECT_THUNK
> +                       "INDIRECT_CALL %[stb]\n"

Besides this being somewhat ugly, having to remember to add
this going forward, should any new indirect calls be added, is
surely prone to be forgotten.

Jan


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