From: Michael Ellerman <patch-notifications@ellerman.id.au>
To: Alexandre Ghiti <alex@ghiti.fr>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Stephen Rothwell <sfr@canb.auug.org.au>,
Alexei Starovoitov <ast@kernel.org>,
linux-next@vger.kernel.org, Zong Li <zong.li@sifive.com>,
Palmer Dabbelt <palmerdabbelt@google.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Subject: Re: [PATCH v2] powerpc: Do not consider weak unresolved symbol relocations as bad
Date: Tue, 4 Feb 2020 23:01:31 +1100 (AEDT) [thread overview]
Message-ID: <48BjwD2PG2zB3ws@ozlabs.org> (raw)
In-Reply-To: <20200118170335.21440-1-alex@ghiti.fr>
On Sat, 2020-01-18 at 17:03:35 UTC, Alexandre Ghiti wrote:
> Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak
> symbols that may be unresolved at link time which result in an absolute
> relocation to 0. relocs_check.sh emits the following warning:
>
> "WARNING: 2 bad relocations
> c000000001a41478 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start
> c000000001a41480 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end"
>
> whereas those relocations are legitimate even for a relocatable kernel
> compiled with -pie option.
>
> relocs_check.sh already excluded some weak unresolved symbols explicitly:
> remove those hardcoded symbols and add some logic that parses the symbols
> using nm, retrieves all the weak unresolved symbols and excludes those from
> the list of the potential bad relocations.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/43e76cd368fbb67e767da5363ffeaa3989993c8c
cheers
prev parent reply other threads:[~2020-02-04 12:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-18 17:03 [PATCH v2] powerpc: Do not consider weak unresolved symbol relocations as bad Alexandre Ghiti
2020-01-30 20:07 ` Alex Ghiti
2020-01-31 9:18 ` Michael Ellerman
2020-02-04 12:01 ` Michael Ellerman [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=48BjwD2PG2zB3ws@ozlabs.org \
--to=patch-notifications@ellerman.id.au \
--cc=alex@ghiti.fr \
--cc=ast@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=palmerdabbelt@google.com \
--cc=paulus@samba.org \
--cc=sfr@canb.auug.org.au \
--cc=zong.li@sifive.com \
/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.