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