--- Begin Message ---
Apologies for the late reply.
Yeah, the other solution to solve this problem is to sprinkle .gotpcrel all
over the x86 assembly whenever it tries to access a variable that's defined
in the C file.
Using `attribute(small)`, as in this patch, is behind a macro that implies
that variable is referenced from the assembly file which only gets
activated for x86 and ELF. We are not putting x86-specific hacks all over
the code. We are putting indicators/macros all over the code against
variables that are defined in C files but accessed in assembly files. This
will also help us to extend the definitions of these macros in future as
alluded to by Andreas and Martin in above discussion. It's good to wrap
these variables that are referenced from external assembly for this reason.
Please make sure you are seeing version 6 of this patch. What you are
describing was done in the first version of this patch.
On Wed, May 7, 2025 at 5:15 AM Rémi Denis-Courmont <r...@remlab.net> wrote:
> Hi,
>
> This looks like a kludge to me. If static variables are too far away, then
> the assembler code that refers to them needs to be fixed, and that's all
> that there is to it.
>
> You can't just magically make the data and the code closer, especially if
> FFmpeg is compiled as a static library (a very common use case).
>
> Also putting x86-specific hacks all over the code base, meh. Other
> architectures have all dealt with that issue cleanly already.
> _______________________________________________
> 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".
>
--- End Message ---
_______________________________________________
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".
