| Message ID | 1345345030-22211-56-git-send-email-andi@firstfloor.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> Andi Kleen <andi@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-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Aug 19, 2012 at 09:46:04AM +0100, Jan Beulich wrote: > >>> Andi Kleen <andi@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
>>> On 19.08.12 at 17:01, Andi Kleen <andi@firstfloor.org> wrote: > On Sun, Aug 19, 2012 at 09:46:04AM +0100, Jan Beulich wrote: >> >>> Andi Kleen <andi@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-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.