Re: [Xen-devel] [PATCH v2 for-next 1/2] x86/string: Clean up the declarations of __builtin_mem*()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.05.17 at 16:34, <andrew.cooper3@xxxxxxxxxx> wrote:
> Rather than #undef'ing macros to avoid altering the function names, use the
> method recommended by the C specification by enclosing the function name in
> brackets to avoid the macro being expanded.  This means that optimisation
> opportunities continue to work in the rest of the translation unit.

That's the upside. The downside is that ...

> --- a/xen/include/asm-x86/string.h
> +++ b/xen/include/asm-x86/string.h
> @@ -2,13 +2,12 @@
>  #define __X86_STRING_H__
>  
>  #define __HAVE_ARCH_MEMCPY
> -#define memcpy(t,f,n) (__builtin_memcpy((t),(f),(n)))
> +#define memcpy(d, s, n)       __builtin_memcpy(d, s, n)
>  
> -/* Some versions of gcc don't have this builtin. It's non-critical anyway. */
>  #define __HAVE_ARCH_MEMMOVE
> -extern void *memmove(void *dest, const void *src, size_t n);
> +#define memmove(d, s, n)      __builtin_memmove(d, s, n)
>  
>  #define __HAVE_ARCH_MEMSET
> -#define memset(s,c,n) (__builtin_memset((s),(c),(n)))
> +#define memset(s, c, n)       __builtin_memset(s, c, n)

with these kinds of #define-s (and with xen/string.h including
asm/string.h before the declarations, which don't get activated
anyway due to the __HAVE_ARCH_MEM* symbols being
#define-d in the context above) you can't use the symbols
in places where function pointers are wanted. IOW I'd prefer
the #undef-s to stay (and string.c explicitly calling the builtins)
and the macros to change to object like ones.

An alternative would be to move the (or add x86 specific)
declarations, making sure the symbols are always available.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel