diff options
author | Palmer Dabbelt <palmerdabbelt@google.com> | 2020-10-24 07:50:47 +0300 |
---|---|---|
committer | Palmer Dabbelt <palmerdabbelt@google.com> | 2020-11-06 11:03:48 +0300 |
commit | c2c81bb2f69138f902e1a58d3bef6ad97fb8a92c (patch) | |
tree | 5251b4b631c953597711d4bcd04147a255621c1f /include/drm/drm_bridge_connector.h | |
parent | 1074dd44c5ba377f90e2d0d99a784f73dbea6ff7 (diff) | |
download | linux-c2c81bb2f69138f902e1a58d3bef6ad97fb8a92c.tar.xz |
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>
Diffstat (limited to 'include/drm/drm_bridge_connector.h')
0 files changed, 0 insertions, 0 deletions