Re: [FFmpeg-devel] [PATCH v4] Mark C globals with small code model

["Martin Storsjö" <martin@martin.st>]

On Wed, 12 Mar 2025, Andreas Rheinhardt wrote:

> Martin Storsjö:
>> On Wed, 12 Mar 2025, Andreas Rheinhardt wrote:
>> 
>>> Pranav Kant via ffmpeg-devel:
>>>> + * all globals in a data section that's unreachable with PC relative
>>>> instructions
>>>> + * (small code model instruction sequence). We mark all such globals
>>>> with this
>>>> + * attribute_mcmodel_small to ensure assembly accessible globals
>>>> continue to be
>>>> + * allocated in sections reachable from PC relative instructions.
>>>> + */
>>>> +#if ARCH_X86_64 && defined(__ELF__) && AV_HAS_ATTRIBUTE(model)
>>>
>>> You make this ARCH_X86_64 only, yet the concept of code models also
>>> exists for other arches, e.g. AArch64. I presume that assembly for other
>>> arches presumes that we are not using the large code model for accesses,
>>> so that the same issue can happen with them. Then we have two options:
>> 
>> FWIW, in e4ac156b7c47725327dff78bb83f5eecbaee3add we added
>> attribute_visibility_hidden to a bunch of symbols that are accessed from
>> aarch64 assembly, in a similar fashion. While the effects are different,
>> I wonder if we should abstract these two down to a more generic
>> attribute for any symbol accessed directly from any assembly.
>> 
>
> As I said above: We would only need two macros: One for any object
> accessed from inline assembly and one for objects accessed by external
> assembly (and not inline assembly). The latter would be hidden
> visibility+small code model, the former would also have av_used. Of
> course, both would allow to specify alignment.
>
> But naming is hard. How about DECLARE_ASM_VAR and DECLARE_INLINE_ASM_VAR?

That sounds ok to me.

// 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-request@ffmpeg.org with subject "unsubscribe".