On Sat, Jan 28, 2023 at 07:52:39AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Jan 27, 2023 at 09:10:22PM -0700, Tom Saeger wrote:
> > sh vmlinux fails to link with GNU ld < 2.40 (likely < 2.36) since
> > commit 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv").
> >
> > This is similar to fixes for powerpc and s390:
> > commit 4b9880dbf3bd ("powerpc/vmlinux.lds: Define RUNTIME_DISCARD_EXIT").
> > commit a494398bde27 ("s390: define RUNTIME_DISCARD_EXIT to fix link error
> > with GNU ld < 2.36").
> >
> > $ sh4-linux-gnu-ld --version | head -n1
> > GNU ld (GNU Binutils for Debian) 2.35.2
> >
> > $ make ARCH=sh CROSS_COMPILE=sh4-linux-gnu- microdev_defconfig
> > $ make ARCH=sh CROSS_COMPILE=sh4-linux-gnu-
> >
> > `.exit.text' referenced in section `__bug_table' of crypto/algboss.o:
> > defined in discarded section `.exit.text' of crypto/algboss.o
> > `.exit.text' referenced in section `__bug_table' of
> > drivers/char/hw_random/core.o: defined in discarded section
> > `.exit.text' of drivers/char/hw_random/core.o
> > make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1
> > make[1]: *** [Makefile:1252: vmlinux] Error 2
> >
> > arch/sh/kernel/vmlinux.lds.S keeps EXIT_TEXT:
> >
> > /*
> > * .exit.text is discarded at runtime, not link time, to deal with
> > * references from __bug_table
> > */
> > .exit.text : AT(ADDR(.exit.text)) { EXIT_TEXT }
> >
> > However, EXIT_TEXT is thrown away by
> > DISCARD(include/asm-generic/vmlinux.lds.h) because
> > sh does not define RUNTIME_DISCARD_EXIT.
> >
> > GNU ld 2.40 does not have this issue and builds fine.
> > This corresponds with Masahiro's comments in a494398bde27:
> > "Nathan [Chancellor] also found that binutils
> > commit 21401fc7bf67 ("Duplicate output sections in scripts") cured this
> > issue, so we cannot reproduce it with binutils 2.36+, but it is better
> > to not rely on it."
> >
> > Fixes: 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv")
> > Link: https://lore.kernel.org/all/Y7Jal56f6UBh1abE@dev-arch.thelio-3990X/
> > Link: https://lore.kernel.org/all/20230123194218.47ssfzhrpnv3xfez@xxxxxxxxxx/
> > Signed-off-by: Tom Saeger <tom.saeger@xxxxxxxxxx>
> > ---
> > arch/sh/kernel/vmlinux.lds.S | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/sh/kernel/vmlinux.lds.S b/arch/sh/kernel/vmlinux.lds.S
> > index 3161b9ccd2a5..791c06b9a54a 100644
> > --- a/arch/sh/kernel/vmlinux.lds.S
> > +++ b/arch/sh/kernel/vmlinux.lds.S
> > @@ -4,6 +4,8 @@
> > * Written by Niibe Yutaka and Paul Mundt
> > */
> > OUTPUT_ARCH(sh)
> > +#define RUNTIME_DISCARD_EXIT
> > +
> > #include <asm/thread_info.h>
> > #include <asm/cache.h>
> > #include <asm/vmlinux.lds.h>
> > --
> > 2.39.1
> >
>
> As my bot said last time you sent this:
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to do this properly.
>
> </formletter>
>
> Sorry, we can not take ANY of this until it hits Linus's tree. You know
> this!
Yep - sorry for the confusion, is it better to send as RFC in cases like
this where folks on list have asked for the series to test?
>
> Please wait until then and then send the needed backports. I'm dropping
> all of these from you from my review queue.
>
> greg k-h
This patch is now in Linus's tree.
c1c551bebf92 ("sh: define RUNTIME_DISCARD_EXIT")
$ git describe --contains c1c551bebf92
v6.2-rc7~18^2~5
commit c1c551bebf928889e7a8fef7415b44f9a64975f4 upstream.
Do you prefer I resend series for 6.1, 5.19, 5.15, and 5.4?
My questions for 6.1 still remain,
https://lore.kernel.org/all/cover.1674876902.git.tom.saeger@xxxxxxxxxx/
This 6.1 series is not strictly necessary, as the problem
does not present itself in the current 6.1 stable kernels.
However, 6.1 WOULD be broken with inclusion of either:
994b7ac1697b ("arm64: remove special treatment for the link order of head.o")
2348e6bf4421 ("riscv: remove special treatment for the link order of head.o")
Should we just include these as well?
My own preference is to included them, to track closer to upstream, and
hopefully avoid 'ld' subtlties going forward.
Thoughts?
--Tom
