Prev: Query: Patches break with Microsoft exchange server.
Next: Today's Linus.git hangs during boot: can't find the floppy controller
From: Andi Kleen on 9 Aug 2010 02:30 Namhyung Kim <namhyung(a)gmail.com> writes: > remove unnecessary use of RELOC_HIDE(). It only does simple addition of ptr > and offset, and in this case, offset 0, does nothing. It does NOT do anything > with linker relocation things. I could find no reason to use it. It's for the benefit of the compiler, we've had miscompilations due to undefined overflow for addresses in the past. The optimizer assumes this won't happen. Given the x86-64 version normally doesn't overflow, but it's still safer to have it. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 9 Aug 2010 02:50 > I'm not talking about the RELOC_HIDE itself. I do know we need it for > some specific case, ie. percpu. But in this case __pa_symbol(x) is > expanded to RELOC_HIDE((unsigned long)(x), 0) which does nothing > meaningful. I believe the overflow is not a concern here. It hides the value conversion from the compiler through asm() -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Namhyung Kim on 9 Aug 2010 02:50 2010-08-09 (월), 08:22 +0200, Andi Kleen: > It's for the benefit of the compiler, we've had miscompilations > due to undefined overflow for addresses in the past. The optimizer > assumes this won't happen. > > Given the x86-64 version normally doesn't overflow, but it's > still safer to have it. > > -Andi > Hi, I'm not talking about the RELOC_HIDE itself. I do know we need it for some specific case, ie. percpu. But in this case __pa_symbol(x) is expanded to RELOC_HIDE((unsigned long)(x), 0) which does nothing meaningful. I believe the overflow is not a concern here. -- Regards, Namhyung Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Namhyung Kim on 9 Aug 2010 03:10 > It hides the value conversion from the compiler through asm() > > -Andi > Yes, indeed. But for what? __pa_symbol() is just used to get the address of some linker symbols in forms of unsigned long which has same bit representation as pointer in x86 (and all supported archs). So do we still need it or am I missing something? -- Regards, Namhyung Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 9 Aug 2010 03:30
On Mon, Aug 09, 2010 at 04:04:45PM +0900, Namhyung Kim wrote: > > It hides the value conversion from the compiler through asm() > > > > -Andi > > > > Yes, indeed. But for what? __pa_symbol() is just used to get the address > of some linker symbols in forms of unsigned long which has same bit > representation as pointer in x86 (and all supported archs). So do we > still need it or am I missing something? The original reason was that the C standard allows the compiler to make some assumptions on the pointer arithmetic that is done on symbol addresses (e.g. no wrapping). This is exploited by the optimizer in the compiler to generate better code. This lead to a miscompilation on PowerPC a couple of years back at least with the va->pa conversion. After that RELOC_HIDE was introduced after funelling the symbol address through an empty asm statement was recommended as the official way to do this by the gcc developers. I think x86-64 does not normally wrap here, but it's still safer to do it this way. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |