When building with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION,
-fdata-sections and -ffunction-sections are being enabled by the
top-level Makefile, and module section merging is also needed.
Expand the ifdef (and the comment block) to cover that case too.
Fixes: 6a3193cdd5e5 ("kbuild: lto: Merge module sections if and only if CONFIG_LTO_CLANG is enabled")
Signed-off-by: Alexander Lobakin <[email protected]>
---
scripts/module.lds.S | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 2c52535f9b56..d6bbdfc55e08 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -20,11 +20,14 @@ SECTIONS {
__patchable_function_entries : { *(__patchable_function_entries) }
-#ifdef CONFIG_LTO_CLANG
+#if defined(CONFIG_LD_DEAD_CODE_DATA_ELIMINATION) || defined(CONFIG_LTO_CLANG)
/*
* With CONFIG_LTO_CLANG, LLD always enables -fdata-sections and
- * -ffunction-sections, which increases the size of the final module.
- * Merge the split sections in the final binary.
+ * -ffunction-sections. With CONFIG_LD_DEAD_CODE_DATA_ELIMINATION,
+ * -fdata-sections and -ffunction-sections are being enabled by
+ * the top-level Makefile.
+ * This increases the size of the final module. Merge the split
+ * sections in the final binary.
*/
.bss : {
*(.bss .bss.[0-9a-zA-Z_]*)
--
2.31.1
On Fri, Apr 2, 2021 at 5:40 AM Alexander Lobakin <[email protected]> wrote:
>
> When building with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION,
> -fdata-sections and -ffunction-sections are being enabled by the
> top-level Makefile, and module section merging is also needed.
> Expand the ifdef (and the comment block) to cover that case too.
>
> Fixes: 6a3193cdd5e5 ("kbuild: lto: Merge module sections if and only if CONFIG_LTO_CLANG is enabled")
Wouldn't this trigger the ld.bfd bug described in the commit message
when LD_DEAD_CODE_DATA_ELIMINATION is enabled? LTO_CLANG always uses
LLD, so it won't have this issue.
Sami
On Friday, 2 April 2021, 18:09, Sami
Tolvanen <[email protected]> wrote:
> On Fri, Apr 2, 2021 at 5:40 AM Alexander Lobakin [email protected] wrote:
>
> > When building with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION,
> > -fdata-sections and -ffunction-sections are being enabled by the
> > top-level Makefile, and module section merging is also needed.
> > Expand the ifdef (and the comment block) to cover that case too.
> > Fixes: 6a3193cdd5e5 ("kbuild: lto: Merge module sections if and only if CONFIG_LTO_CLANG is enabled")
>
> Wouldn't this trigger the ld.bfd bug described in the commit message
> when LD_DEAD_CODE_DATA_ELIMINATION is enabled? LTO_CLANG always uses
> LLD, so it won't have this issue.
LD_DEAD_CODE_DATA_ELIMINATION is marked
“EXPERIMENTAL“ in the config prompt, and
arches have to opt-in
HAS_LD_DEAD_CODE_DATA_ELIMINATION to give
an access to it (only a few does). This
should be relatively safe.
> Sami
Thanks,
Al
On Tue, Apr 6, 2021 at 11:42 PM Alexander Lobakin <[email protected]> wrote:
>
> On Friday, 2 April 2021, 18:09, Sami
> Tolvanen <[email protected]> wrote:
>
> > On Fri, Apr 2, 2021 at 5:40 AM Alexander Lobakin [email protected] wrote:
> >
> > > When building with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION,
> > > -fdata-sections and -ffunction-sections are being enabled by the
> > > top-level Makefile, and module section merging is also needed.
> > > Expand the ifdef (and the comment block) to cover that case too.
> > > Fixes: 6a3193cdd5e5 ("kbuild: lto: Merge module sections if and only if CONFIG_LTO_CLANG is enabled")
Did you test this patch before submission?
See the top Makefile closely:
ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
KBUILD_CFLAGS_KERNEL += -ffunction-sections -fdata-sections
LDFLAGS_vmlinux += --gc-sections
endif
-ffunction-sections -fdata-sections are passed to only
built-in objects, but not to module objects in the
first place.
KBUILD_CFLAGS_KERNEL is only passed to built-in objects.
The situation you claimed never happens.
> > Wouldn't this trigger the ld.bfd bug described in the commit message
> > when LD_DEAD_CODE_DATA_ELIMINATION is enabled? LTO_CLANG always uses
> > LLD, so it won't have this issue.
>
> LD_DEAD_CODE_DATA_ELIMINATION is marked
> “EXPERIMENTAL“ in the config prompt, and
> arches have to opt-in
> HAS_LD_DEAD_CODE_DATA_ELIMINATION to give
> an access to it (only a few does). This
> should be relatively safe.
>
> > Sami
>
> Thanks,
> Al
--
Best Regards
Masahiro Yamada