On Thu, 14 Jul 2022, Martin Storsjö wrote:
The AArch64 assembly accesses those symbols directly, without
indirection via e.g. the GOT on ELF. In order for this not to
require text relocations, those symbols need to be resolved fully
at link time, i.e. those symbols can't be interposable.
Normally, so far, this is achieved when linking shared libraries
in two ways; we have a version script (libavcodec/libavcodec.v) which
marks all symbols that don't start with av* as local. Additionally,
we try to add -Wl,-Bsymbolic to the linker options if supported,
making sure that such symbol references are resolved fully at link
time, instead of making them interposable.
When the libavcodec static library is linked into another shared
library, there's no guarantee that it uses similar options (even though
that would be favourable), which would end up requiring text relocations
in the AArch64 assembly.
Explicitly mark the symbols that are accessed from AArch64 assembly
as hidden, so that they are resolved fully at link time even without
the version script and -Wl,-Bsymbolic.
Signed-off-by: Martin Storsjö <mar...@martin.st>
---
Moved the attribute to libavutil/internal.h, renamed to a different
namespace (not av_ prefixed), moved the attribute on ff_vp9_subpel_filters
to the header, as suggested.
Added explicit includes of libavutil/internal.h to fix builds on
x86.
---
libavcodec/aacsbrdata.h | 3 ++-
libavcodec/fft.h | 3 ++-
libavcodec/vp9dsp.h | 3 ++-
libavutil/internal.h | 6 ++++++
4 files changed, 12 insertions(+), 3 deletions(-)
Ping - any further comments on this - is it acceptable/tolerable, as a
practical fix to make sure these symbols aren't interposable?
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
