linux.git - Linus' kernel tree

Age	Commit message (Collapse)	Author
2021-08-24	riscv: explicitly use symbol offsets for VDSO	Saleem Abdulrasool
	The current implementation of the `__rt_sigaction` reference computed an absolute offset relative to the mapped base of the VDSO. While this can be handled in the medlow model, the medany model cannot handle this as it is meant to be position independent. The current implementation relied on the BFD linker relaxing the PC-relative relocation into an absolute relocation as it was a near-zero address allowing it to be referenced relative to `zero`. We now extract the offsets and create a generated header allowing the build with LLVM and lld to succeed as we no longer depend on the linker rewriting address references near zero. This change was largely modelled after the ARM64 target which does something similar. Signed-off-by: Saleem Abdulrasool <abdulras@google.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-11-06	RISC-V: Fix the VDSO symbol generaton for binutils-2.35+	Palmer Dabbelt
	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>