x86: remove __phys_reloc_hide
in [Kernel]
|
Prev: Query: Patches break with Microsoft exchange server.
Next: Today's Linus.git hangs during boot: can't find the floppy controller
From: Namhyung Kim on 9 Aug 2010 03:50 2010-08-09 (월), 09:22 +0200, Andi Kleen: > 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 OK, then. Thanks for the comment. p.s. The funny thing I found is there's no use of RELOC_HIDE on arch/powerpc. Hmm... -- 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: Ingo Molnar on 9 Aug 2010 04:10 * Namhyung Kim <namhyung(a)gmail.com> wrote: > 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. > > The only user of __phys_reloc_hide() was __pa_symbol() so it can be removed > safely here. > > Signed-off-by: Namhyung Kim <namhyung(a)gmail.com> > --- > arch/x86/include/asm/page.h | 5 ++--- > arch/x86/include/asm/page_32.h | 1 - > arch/x86/include/asm/page_64_types.h | 1 - > 3 files changed, 2 insertions(+), 5 deletions(-) We do this as a general Voodoo barrier against GCC miscompilations. You are right that it's largely moot by today (and especially so on x86 - i only remember a single instance of miscompilation that Rusty mentioned few years ago, and that was on powerpc), but the wrapper is simple enough, so unless there's some real tangible improvement in the binary output we might as well keep it. Peter, what do you think? Ingo -- 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: H. Peter Anvin on 9 Aug 2010 15:00 On 08/09/2010 12:22 AM, Andi Kleen wrote: > 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. > We pass -fno-strict-overflow to the kernel now, which takes care of the underlying problem, at least for current versions of gcc. Unfortunately we still have people who want to use very old gcc versions to compile the kernel, so it's probably better to leave it in at least until we formally kill off support for gcc 3. -hpa -- 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: Ingo Molnar on 10 Aug 2010 03:10 * H. Peter Anvin <hpa(a)zytor.com> wrote: > On 08/09/2010 12:22 AM, Andi Kleen wrote: > > 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. > > > > We pass -fno-strict-overflow to the kernel now, which takes care of the > underlying problem, at least for current versions of gcc. Unfortunately > we still have people who want to use very old gcc versions to compile > the kernel, so it's probably better to leave it in at least until we > formally kill off support for gcc 3. Namhyung, mind sending a patch that adds a comment to __pa_symbol() to point out the connection to -fno-strict-overflow and that it can be removed once all supported versions of GCC understand -fno-strict-overflow? That would make for one less piece of legacy voodoo code in the kernel ;-) Thanks, Ingo -- 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 10 Aug 2010 06:50
2010-08-10 (화), 09:05 +0200, Ingo Molnar: > * H. Peter Anvin <hpa(a)zytor.com> wrote: > > > We pass -fno-strict-overflow to the kernel now, which takes care of the > > underlying problem, at least for current versions of gcc. Unfortunately > > we still have people who want to use very old gcc versions to compile > > the kernel, so it's probably better to leave it in at least until we > > formally kill off support for gcc 3. > > Namhyung, mind sending a patch that adds a comment to __pa_symbol() to point > out the connection to -fno-strict-overflow and that it can be removed once all > supported versions of GCC understand -fno-strict-overflow? > > That would make for one less piece of legacy voodoo code in the kernel ;-) > > Thanks, > > Ingo No problem. :-) But before that, let me clarify this: It seems -fno-strict-overflow is all about the signed arithmetic and __pa_symbol() does unsigned one. Is it really matters 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/ |