From: Nathan Chancellor <nathan@kernel.org>
To: Martin Wetterwald <martin@wetterwald.eu>
Cc: linus.walleij@linaro.org, linux@armlinux.org.uk,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: Linux linking stage broken on ARM with binutils 2.33.1 (BFD)
Date: Tue, 8 Jul 2025 18:21:34 -0700 [thread overview]
Message-ID: <20250709012134.GA1785682@ax162> (raw)
In-Reply-To: <CAFERDQ0zPoya5ZQfpbeuKVZEo_fKsonLf6tJbp32QnSGAtbi+Q@mail.gmail.com>
Hi Martin,
On Tue, Jul 08, 2025 at 09:44:44PM +0200, Martin Wetterwald wrote:
> When I upgraded from 6.12.22 to 6.12.23 (without changing anything else), the
> linking stage of vmlinux broke (arch ARM).
>
> > /home/.../linux-6.12.23/scripts/link-vmlinux.sh: line 49: 136961 Segmentation fault (core dumped) ${ld} ${ldflags} -o ${output} ${wl}--whole-archive ${objs} ${wl}--no-whole-archive ${wl}--start-group ${libs} ${wl}--end-group ${kallsymso} ${btf_vmlinux_bin_o} ${ldlibs}
> > make[2]: *** [/home/.../linux-6.12.23/scripts/Makefile.vmlinux:34: vmlinux] Error 139
> > make[1]: *** [/home/.../linux-6.12.23/Makefile:1179: vmlinux] Error 2
> > make: *** [/home/.../linux-6.12.23/Makefile:224: __sub-make] Error 2
>
> This patch seems related:
>
> > commit 59fc42318305cb38efb4f5565408150419be8451
> > Author: Nathan Chancellor <nathan@kernel.org>
> > Date: Thu Mar 20 22:33:49 2025 +0100
> >
> > ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE
> >
> > commit e7607f7d6d81af71dcc5171278aadccc94d277cd upstream.
> >
> > ld.lld prior to 21.0.0 does not support using the KEEP keyword within an
> > overlay description, which may be needed to avoid discarding necessary
> > sections within an overlay with '--gc-sections', which can be enabled
> > for the kernel via CONFIG_LD_DEAD_CODE_DATA_ELIMINATION.
> >
> > Disallow CONFIG_LD_DEAD_CODE_DATA_ELIMINATION without support for KEEP
> > within OVERLAY and introduce a macro, OVERLAY_KEEP, that can be used to
> > conditionally add KEEP when it is properly supported to avoid breaking
> > old versions of ld.lld.
> >
> > Cc: stable@vger.kernel.org
> > Link: https://github.com/llvm/llvm-project/commit/381599f1fe973afad3094e55ec99b1620dba7d8c
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > [nathan: Fix conflict in init/Kconfig due to lack of RUSTC symbols]
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> I'm using BFD linker from GNU binutils 2.33.1 (built using musl-cross-make with
> musl 1.2.5 and GCC 14).
>
> > scripts/ld-version.sh /tmp/arm-linux-musleabihf-ld
> > BFD 23301
>
> I don't know if it was the intention of the patch, but it is not only changing
> a behavior for LLD, but also for BFD:
> - Before the patch, ld BFD 2.33.1 was not selecting
> HAVE_LD_DEAD_CODE_DATA_ELIMINATION, and my build worked.
> - After the patch, ld BFD 2.33.1 is activating
> HAVE_LD_DEAD_CODE_DATA_ELIMINATION, and it is segfaulting.
> Shouldn't we keep the previous behavior and only select this option when BFD is
> >= 2.36.0 (and not just when we have a BFD linker) ?
>
> The issue is the interaction between LD_CAN_USE_KEEP_IN_OVERLAY and
> HAVE_LD_DEAD_CODE_DATA_ELIMINATION.
>
> Nathan, I've seen your proposal here: https://lkml.org/lkml/2025/7/5/431.
> I confirm it also fixes the issue on my side. Should I propose the patch?
Yes, your analysis is spot on, sorry again for the breakage :(
I sent that diff to the list formally yesterday:
https://lore.kernel.org/all/20250707-arm-fix-dce-older-binutils-v1-1-3b5e59dc3b26@kernel.org/
I plan to put it in Russell's patch tracker for application in the next
couple of days, I wanted to wait a few days for the opportunity for
review.
Cheers,
Nathan
prev parent reply other threads:[~2025-07-09 1:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-08 19:44 Linux linking stage broken on ARM with binutils 2.33.1 (BFD) Martin Wetterwald
2025-07-09 1:21 ` Nathan Chancellor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250709012134.GA1785682@ax162 \
--to=nathan@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=martin@wetterwald.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.