[FFmpeg-devel] [PATCH] avcodec/aarch64: Access externs via GOT with PIC

[Martin Storsjö]

On Mon, 11 Jul 2022, Martin Storsjö wrote:

> Hi,
>
> Thanks for your patch! While the patch probably is worthwhile to pursue, 
> ffmpeg does work on Android 6 and newer (with the aarch64 assembly), so 
> there's some gaps/misses in the reasoning in the patch description.
>
> On Sun, 10 Jul 2022, Triang3l wrote:
>
>> To support PIC, all AArch64 assembly code in FFmpeg uses the `movrel` macro 
>> to obtain addresses of labels, such as lookup table constants, in a way 
>> that with CONFIG_PIC being 1, PC-relative addresses of labels are computed 
>> via the `adrp` instruction.
>
>> This approach, however, is suitable only for labels defined in the same 
>> object file. For `adrp` to work directly between object files, the linker 
>> has to perform a text relocation.
>
> No, it doesn't. It's fully possible to build such libraries without text 
> relocations currently.
>
> My memory of the situation was that we're linking our shared libraries with 
> -Wl,-Bsymbolic, which means that those symbol references are bound at link 
> time, so the offset from adrp to the target symbol is fixed at link time, and 
> no text relocation is needed.
>
> However I did try to link such shared libraries, removing the -Wl,-Bsymbolic 
> argument, and it still succeeds. So I'm a bit unsure what really makes it 
> work for me when it isn't working for you.

Andreas Rheinhardt kindly reminded me that when linking libavcodec.so, we 
add -Wl,--version-script,libavcodec/libavcodec.ver, which makes e.g. 
ff_cos_32 a non-exported symbol, which means that it can't be interposed, 
and thus the relocation can be fixed at link time.

If I remove that argument, I can reproduce the linker errors, and adding 
-Wl,-Bsymbolic fixes it.

I wonder if we could mark these symbols as ELF hidden, so that they 
wouldn't need to be interposable at all, even when you link the static 
library into a separate shared library?

// Martin