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/
