>>> On 12.05.17 at 16:34, <andrew.coop...@citrix.com> 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@lists.xen.org https://lists.xen.org/xen-devel
