]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
RISC-V: Fix the VDSO symbol generaton for binutils-2.35+
authorPalmer Dabbelt <palmerdabbelt@google.com>
Sat, 24 Oct 2020 04:50:47 +0000 (21:50 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 18 Nov 2020 18:22:08 +0000 (19:22 +0100)
commitcc8570e6122e9ee1bd53ecaeeccd47c36e858177
tree6abcbe28d69624d447f3d94d6ded6369c57581b6
parent6809b33291367c07ccaab29c4e366b762b832fe3
RISC-V: Fix the VDSO symbol generaton for binutils-2.35+

[ Upstream commit c2c81bb2f69138f902e1a58d3bef6ad97fb8a92c ]

We were relying on GNU ld's ability to re-link executable files in order
to extract our VDSO symbols.  This behavior was deemed a bug as of
binutils-2.35 (specifically the binutils-gdb commit a87e1817a4 ("Have
the linker fail if any attempt to link in an executable is made."), but
as that has been backported to at least Debian's binutils-2.34 in may
manifest in other places.

The previous version of this was a bit of a mess: we were linking a
static executable version of the VDSO, containing only a subset of the
input symbols, which we then linked into the kernel.  This worked, but
certainly wasn't a supported path through the toolchain.  Instead this
new version parses the textual output of nm to produce a symbol table.
Both rely on near-zero addresses being linkable, but as we rely on weak
undefined symbols being linkable elsewhere I don't view this as a major
issue.

Fixes: e2c0cdfba7f6 ("RISC-V: User-facing API")
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
arch/riscv/kernel/vdso/.gitignore
arch/riscv/kernel/vdso/Makefile
arch/riscv/kernel/vdso/so2s.sh [new file with mode: 0755]