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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux