From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Huacai Chen <chenhuacai@kernel.org>
Cc: Huacai Chen <chenhuacai@loongson.cn>,
Sasha Levin <sashal@kernel.org>, Xuerui Wang <kernel@xen0n.name>,
Masahiro Yamada <masahiroy@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Nicolas Schier <nicolas@fjasle.eu>,
stable@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH 6.1&6.6 0/3] kbuild: Avoid weak external linkage where possible
Date: Sat, 7 Dec 2024 10:32:19 +0100 [thread overview]
Message-ID: <2024120748-preaching-reshape-06e9@gregkh> (raw)
In-Reply-To: <CAAhV-H4Db0tVrqcfXHceJeODgnK0ggHpx9_6vwXAAV0LohCD-w@mail.gmail.com>
On Sat, Dec 07, 2024 at 05:21:00PM +0800, Huacai Chen wrote:
> Hi, Greg,
>
> On Fri, Dec 6, 2024 at 9:04 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Dec 06, 2024 at 04:58:07PM +0800, Huacai Chen wrote:
> > > Backport this series to 6.1&6.6 because LoongArch gets build errors with
> > > latest binutils which has commit 599df6e2db17d1c4 ("ld, LoongArch: print
> > > error about linking without -fPIC or -fPIE flag in more detail").
> > >
> > > CC .vmlinux.export.o
> > > UPD include/generated/utsversion.h
> > > CC init/version-timestamp.o
> > > LD .tmp_vmlinux.kallsyms1
> > > loongarch64-unknown-linux-gnu-ld: kernel/kallsyms.o:(.text+0): relocation R_LARCH_PCALA_HI20 against `kallsyms_markers` can not be used when making a PIE object; recompile with -fPIE
> > > loongarch64-unknown-linux-gnu-ld: kernel/crash_core.o:(.init.text+0x984): relocation R_LARCH_PCALA_HI20 against `kallsyms_names` can not be used when making a PIE object; recompile with -fPIE
> > > loongarch64-unknown-linux-gnu-ld: kernel/bpf/btf.o:(.text+0xcc7c): relocation R_LARCH_PCALA_HI20 against `__start_BTF` can not be used when making a PIE object; recompile with -fPIE
> > > loongarch64-unknown-linux-gnu-ld: BFD (GNU Binutils) 2.43.50.20241126 assertion fail ../../bfd/elfnn-loongarch.c:2673
> > >
> > > In theory 5.10&5.15 also need this, but since LoongArch get upstream at
> > > 5.19, so I just ignore them because there is no error report about other
> > > archs now.
> >
> > Odd, why doesn't this affect other arches as well using new binutils? I
> > hate to have to backport all of this just for one arch, as that feels
> > odd.
> The related binutils commit is only for LoongArch, so build errors
> only occured on LoongArch. I don't know why other archs have no
> problem exactly, but may be related to their CFLAGS (for example, if
> we disable CONFIG_RELOCATABLE, LoongArch also has no build errors
> because CFLAGS changes).
does LoongArch depend on that option? What happens if it is enabled for
other arches? Why doesn't it break them?
> On the other hand, Ard's original patches are not for LoongArch only,
> so I think backport to stable branches is also not for LoongArch only.
Maybe Ard can answer that.
thanks,
greg k-h
next prev parent reply other threads:[~2024-12-07 9:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 8:58 [PATCH 6.1&6.6 0/3] kbuild: Avoid weak external linkage where possible Huacai Chen
2024-12-06 8:58 ` [PATCH 6.1&6.6 1/3] kallsyms: Avoid weak references for kallsyms symbols Huacai Chen
2024-12-06 8:58 ` [PATCH 6.1&6.6 2/3] vmlinux: Avoid weak reference to notes section Huacai Chen
2024-12-06 8:58 ` [PATCH 6.1&6.6 3/3] btf: Avoid weak external references Huacai Chen
2024-12-06 13:04 ` [PATCH 6.1&6.6 0/3] kbuild: Avoid weak external linkage where possible Greg Kroah-Hartman
2024-12-07 9:21 ` Huacai Chen
2024-12-07 9:32 ` Greg Kroah-Hartman [this message]
2024-12-07 10:46 ` Xi Ruoyao
2024-12-09 8:31 ` Ard Biesheuvel
2024-12-09 10:01 ` Xi Ruoyao
2025-02-06 8:37 ` WangYuli
2025-02-06 9:31 ` Ard Biesheuvel
2025-02-06 10:03 ` Greg KH
2025-09-05 6:49 ` Ming Wang
2025-09-05 7:09 ` Greg KH
2025-09-05 8:29 ` Ming Wang
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=2024120748-preaching-reshape-06e9@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=ardb@kernel.org \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=kernel@xen0n.name \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nicolas@fjasle.eu \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox