Re: linux-next: manual merge of the rr tree

[Rusty Russell <rusty@rustcorp.com.au>]

On Wednesday 07 January 2009 01:35:57 Christoph Lameter wrote:
> +/* This macro obfuscates arithmetic on a variable address so that gcc
> +   shouldn't recognize it. This prevents optimizations such as the
> +   famous:
> +	strcpy(s, "xxx"+X) => memcpy(s, "xxx"+X, 4-X) */
> +#define reloc_hide(var, off)						\
> +  ({ __typeof__(&(var)) __ptr;					\
> +    __asm__ ("" : "=g"(__ptr) : "0"((void *)&(var) + (off)));	\
> +    *__ptr; })
> 
> I dont get the point here.

This one example of gcc making assumptions about pointer arithmetic.  It's
perfectly reasonable.  It's also unhelpful cases like for per-cpu offsets.

Thus we use this macro to prevent GCC from making such assumptions.

We can't audit current and future gcc versions to see what other
optimizations might break our code on every arch.  I just documented it,
and followed Richard's advice.

Am I missing a downside?

> Could we clearly document what the point of RELOC_HIDE is?

Sorry, I'm not sure I can improve on the current comment:

/* This macro obfuscates arithmetic on a variable address so that gcc
   shouldn't recognize the original var, and make assumptions about it */

Cheers,
Rusty.