On Wed, 7 Jan 2009, Rusty Russell wrote:
> > + 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.
What assumption does GCC make that would cause problems?
> Thus we use this macro to prevent GCC from making such assumptions.
Never seen any ill effect from just using a pointer recast and add.
> 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?
GCC cannot optimize the pointer arithmetic with the strange asm code. It
seems that no one really knows what the exact purpose of RELOC_HIDE is.
One issue may be that issue of pointer into an object not being valid if
they are made to point outside of the object?
> > 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 */
What assumptions? Obviously you still want the linker relocation to
happen.
--
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
