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 17:20, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/05/17 15:52, Jan Beulich wrote:
>>>>> 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.
> 
> Unfortunately, Clang objects to using object-like macros
> 
> setup.c:1671:29: error: builtin functions must be directly called
>     printk("Test: %zu", foo(__builtin_strlen));

Which makes sense, as they aren't actual functions.

> The only way  this is going to work is in the same style as how the
> compiler header files already do it, which is in the style above.  I
> will see about fixing the symbol declarations so they can be used as
> function pointers.

Thanks.

Jan


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