linux/arch/riscv/kernel/vdso/so2s.sh

#!/bin/sh
# SPDX-License-Identifier: GPL-2.0+
# Copyright 2020 Palmer Dabbelt <palmerdabbelt@google.com>

sed 's!\([0-9a-f]*\) T \([a-z0-9_]*\)\(@@LINUX_4.15\)*!.global \2\n.set \2,0x\1!' \
| grep '^\.'
RISC-V: Fix the VDSO symbol generaton for binutils-2.35+ 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> 2020-10-24 04:50:47 +00:00			`#!/bin/sh`
			`# SPDX-License-Identifier: GPL-2.0+`
			`# Copyright 2020 Palmer Dabbelt <palmerdabbelt@google.com>`

			`sed 's!\([0-9a-f]\) T \([a-z0-9_]\)\(@@LINUX_4.15\)*!.global \2\n.set \2,0x\1!' \`
			`\| grep '^\.'`