Re: [PATCH 55/74] lto, workaround: Add workaround for initcall reordering
>>> On 19.08.12 at 17:01, Andi Kleen wrote: > On Sun, Aug 19, 2012 at 09:46:04AM +0100, Jan Beulich wrote: >> >>> Andi Kleen 08/19/12 5:05 AM >>> >> >Work around a LTO gcc problem: when there is no reference to a variable >> >in a module it will be moved to the end of the program. This causes >> >reordering of initcalls which the kernel does not like. >> >Add a dummy reference function to avoid this. The function is >> >deleted by the linker. >> >> This is not even true on x86, not to speak of generally. > > Why is it not true ? > > __initcall is only defined for !MODULE and there __exit discards. __exit, on x86 and perhaps other arches, causes the code to be discarded at runtime only. >> >+#ifdef CONFIG_LTO >> >+/* Work around a LTO gcc problem: when there is no reference to a variable >> >+ * in a module it will be moved to the end of the program. This causes >> >+ * reordering of initcalls which the kernel does not like. >> >+ * Add a dummy reference function to avoid this. The function is >> >+ * deleted by the linker. >> >+ */ >> >+#define LTO_REFERENCE_INITCALL(x) \ >> >+; /* yes this is needed */\ >> >+static __used __exit void *reference_##x(void) \ >> >> Why not put it into e.g. section .discard.text? That could be expected to be >> discarded by the linker without being arch dependent, as long as all arches >> use DISCARDS in their linker script. > > > That's what __exit does, doesn't it? No - see above. Using .discard.* enforces the discarding at link time. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 55/74] lto, workaround: Add workaround for initcall reordering
On 19.08.12 at 17:01, Andi Kleen a...@firstfloor.org wrote: On Sun, Aug 19, 2012 at 09:46:04AM +0100, Jan Beulich wrote: Andi Kleen a...@firstfloor.org 08/19/12 5:05 AM Work around a LTO gcc problem: when there is no reference to a variable in a module it will be moved to the end of the program. This causes reordering of initcalls which the kernel does not like. Add a dummy reference function to avoid this. The function is deleted by the linker. This is not even true on x86, not to speak of generally. Why is it not true ? __initcall is only defined for !MODULE and there __exit discards. __exit, on x86 and perhaps other arches, causes the code to be discarded at runtime only. +#ifdef CONFIG_LTO +/* Work around a LTO gcc problem: when there is no reference to a variable + * in a module it will be moved to the end of the program. This causes + * reordering of initcalls which the kernel does not like. + * Add a dummy reference function to avoid this. The function is + * deleted by the linker. + */ +#define LTO_REFERENCE_INITCALL(x) \ +; /* yes this is needed */\ +static __used __exit void *reference_##x(void) \ Why not put it into e.g. section .discard.text? That could be expected to be discarded by the linker without being arch dependent, as long as all arches use DISCARDS in their linker script. That's what __exit does, doesn't it? No - see above. Using .discard.* enforces the discarding at link time. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 55/74] lto, workaround: Add workaround for initcall reordering
On Sun, Aug 19, 2012 at 09:46:04AM +0100, Jan Beulich wrote: > >>> Andi Kleen 08/19/12 5:05 AM >>> > >Work around a LTO gcc problem: when there is no reference to a variable > >in a module it will be moved to the end of the program. This causes > >reordering of initcalls which the kernel does not like. > >Add a dummy reference function to avoid this. The function is > >deleted by the linker. > > This is not even true on x86, not to speak of generally. Why is it not true ? __initcall is only defined for !MODULE and there __exit discards. > > >+#ifdef CONFIG_LTO > >+/* Work around a LTO gcc problem: when there is no reference to a variable > >+ * in a module it will be moved to the end of the program. This causes > >+ * reordering of initcalls which the kernel does not like. > >+ * Add a dummy reference function to avoid this. The function is > >+ * deleted by the linker. > >+ */ > >+#define LTO_REFERENCE_INITCALL(x) \ > >+; /* yes this is needed */\ > >+static __used __exit void *reference_##x(void) \ > > Why not put it into e.g. section .discard.text? That could be expected to be > discarded by the linker without being arch dependent, as long as all arches > use DISCARDS in their linker script. That's what __exit does, doesn't it? -Andi -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 55/74] lto, workaround: Add workaround for initcall reordering
>>> Andi Kleen 08/19/12 5:05 AM >>> >Work around a LTO gcc problem: when there is no reference to a variable >in a module it will be moved to the end of the program. This causes >reordering of initcalls which the kernel does not like. >Add a dummy reference function to avoid this. The function is >deleted by the linker. This is not even true on x86, not to speak of generally. >+#ifdef CONFIG_LTO >+/* Work around a LTO gcc problem: when there is no reference to a variable >+ * in a module it will be moved to the end of the program. This causes >+ * reordering of initcalls which the kernel does not like. >+ * Add a dummy reference function to avoid this. The function is >+ * deleted by the linker. >+ */ >+#define LTO_REFERENCE_INITCALL(x) \ >+; /* yes this is needed */\ >+static __used __exit void *reference_##x(void) \ Why not put it into e.g. section .discard.text? That could be expected to be discarded by the linker without being arch dependent, as long as all arches use DISCARDS in their linker script. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 55/74] lto, workaround: Add workaround for initcall reordering
Andi Kleen a...@firstfloor.org 08/19/12 5:05 AM Work around a LTO gcc problem: when there is no reference to a variable in a module it will be moved to the end of the program. This causes reordering of initcalls which the kernel does not like. Add a dummy reference function to avoid this. The function is deleted by the linker. This is not even true on x86, not to speak of generally. +#ifdef CONFIG_LTO +/* Work around a LTO gcc problem: when there is no reference to a variable + * in a module it will be moved to the end of the program. This causes + * reordering of initcalls which the kernel does not like. + * Add a dummy reference function to avoid this. The function is + * deleted by the linker. + */ +#define LTO_REFERENCE_INITCALL(x) \ +; /* yes this is needed */\ +static __used __exit void *reference_##x(void) \ Why not put it into e.g. section .discard.text? That could be expected to be discarded by the linker without being arch dependent, as long as all arches use DISCARDS in their linker script. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 55/74] lto, workaround: Add workaround for initcall reordering
On Sun, Aug 19, 2012 at 09:46:04AM +0100, Jan Beulich wrote: Andi Kleen a...@firstfloor.org 08/19/12 5:05 AM Work around a LTO gcc problem: when there is no reference to a variable in a module it will be moved to the end of the program. This causes reordering of initcalls which the kernel does not like. Add a dummy reference function to avoid this. The function is deleted by the linker. This is not even true on x86, not to speak of generally. Why is it not true ? __initcall is only defined for !MODULE and there __exit discards. +#ifdef CONFIG_LTO +/* Work around a LTO gcc problem: when there is no reference to a variable + * in a module it will be moved to the end of the program. This causes + * reordering of initcalls which the kernel does not like. + * Add a dummy reference function to avoid this. The function is + * deleted by the linker. + */ +#define LTO_REFERENCE_INITCALL(x) \ +; /* yes this is needed */\ +static __used __exit void *reference_##x(void) \ Why not put it into e.g. section .discard.text? That could be expected to be discarded by the linker without being arch dependent, as long as all arches use DISCARDS in their linker script. That's what __exit does, doesn't it? -Andi -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 55/74] lto, workaround: Add workaround for initcall reordering
From: Andi Kleen Work around a LTO gcc problem: when there is no reference to a variable in a module it will be moved to the end of the program. This causes reordering of initcalls which the kernel does not like. Add a dummy reference function to avoid this. The function is deleted by the linker. This replaces a previous much slower workaround. Thanks to Honza Hubicka for suggesting this technique. Signed-off-by: Andi Kleen --- include/linux/init.h | 20 +++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/include/linux/init.h b/include/linux/init.h index c2f06b3..e425800 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -176,6 +176,23 @@ extern bool initcall_debug; #ifndef __ASSEMBLY__ +#ifdef CONFIG_LTO +/* Work around a LTO gcc problem: when there is no reference to a variable + * in a module it will be moved to the end of the program. This causes + * reordering of initcalls which the kernel does not like. + * Add a dummy reference function to avoid this. The function is + * deleted by the linker. + */ +#define LTO_REFERENCE_INITCALL(x) \ + ; /* yes this is needed */ \ + static __used __exit void *reference_##x(void) \ + { \ + return \ + } +#else +#define LTO_REFERENCE_INITCALL(x) +#endif + /* initcalls are now grouped by functionality into separate * subsections. Ordering inside the subsections is determined * by link order. @@ -188,7 +205,8 @@ extern bool initcall_debug; #define __define_initcall(level,fn,id) \ static initcall_t __initcall_##fn##id __used \ - __attribute__((__section__(".initcall" level ".init"))) = fn + __attribute__((__section__(".initcall" level ".init"))) = fn \ + LTO_REFERENCE_INITCALL(__initcall_##fn##id) /* * Early initcalls run before initializing SMP. -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 55/74] lto, workaround: Add workaround for initcall reordering
From: Andi Kleen a...@linux.intel.com Work around a LTO gcc problem: when there is no reference to a variable in a module it will be moved to the end of the program. This causes reordering of initcalls which the kernel does not like. Add a dummy reference function to avoid this. The function is deleted by the linker. This replaces a previous much slower workaround. Thanks to Honza Hubicka for suggesting this technique. Signed-off-by: Andi Kleen a...@linux.intel.com --- include/linux/init.h | 20 +++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/include/linux/init.h b/include/linux/init.h index c2f06b3..e425800 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -176,6 +176,23 @@ extern bool initcall_debug; #ifndef __ASSEMBLY__ +#ifdef CONFIG_LTO +/* Work around a LTO gcc problem: when there is no reference to a variable + * in a module it will be moved to the end of the program. This causes + * reordering of initcalls which the kernel does not like. + * Add a dummy reference function to avoid this. The function is + * deleted by the linker. + */ +#define LTO_REFERENCE_INITCALL(x) \ + ; /* yes this is needed */ \ + static __used __exit void *reference_##x(void) \ + { \ + return x; \ + } +#else +#define LTO_REFERENCE_INITCALL(x) +#endif + /* initcalls are now grouped by functionality into separate * subsections. Ordering inside the subsections is determined * by link order. @@ -188,7 +205,8 @@ extern bool initcall_debug; #define __define_initcall(level,fn,id) \ static initcall_t __initcall_##fn##id __used \ - __attribute__((__section__(.initcall level .init))) = fn + __attribute__((__section__(.initcall level .init))) = fn \ + LTO_REFERENCE_INITCALL(__initcall_##fn##id) /* * Early initcalls run before initializing SMP. -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/