On Sat, 21 Feb 2015, Janne Grunau wrote:
On 2015-02-18 00:44:14 +0200, Martin Storsjö wrote:
When all the codepaths using manually set .arch/.fpu code is
behind runtime detection, the elf attributes should be suppressed.
Are you sure everything is behind runtime detection? It probably is
since everything without runtime detection is probably in inline asm so
it can be inlined.
It should be - I hope. If the compiler is free to output such instructions
unconditionally, compiler generated files will have such tags set anyway.
This allows tools to know that the final built binary doesn't
strictly require these extensions.
---
Ideally, these should only be added on platforms where we have
runtime detection (i.e. linux). So on non-linux, ELF platforms,
they should in theory be omitted. Adding #ifdef __linux__ around
them do feel like overkill though.
as you said nothing bad will happen. The code remains behind runtime
detection although the runtime detections is degraded to a compile time
constant. Actually I think it's better to set .eabi_attributes
unconditionally. It won't require further changes when we add real
runtime detection to other platforms.
True, that sounds sensible.
---
libavutil/arm/asm.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/arm/asm.S b/libavutil/arm/asm.S
index 8479304..63e292d 100644
--- a/libavutil/arm/asm.S
+++ b/libavutil/arm/asm.S
@@ -49,9 +49,12 @@
#elif HAVE_ARMV5TE
.arch armv5te
#endif
+ELF .object_arch armv4
is .object_arch understood by all assemblers? Main one to worry about is
probably llvm's integrated assembler. Do we use/support something else
for elf targets?
Haven't tested LLVM's integrated assembler - can you test it? The other
major weird one is symbian which also uses ELF, but that's only an old gnu
binutils.
#if HAVE_NEON
.fpu neon
+ELF .eabi_attribute 10, 0 @ suppress Tag_FP_arch
+ELF .eabi_attribute 12, 0 @ suppress Tag_Advanced_SIMD_arch
#elif HAVE_VFP
.fpu vfp
Any reason not to suppress Tag_FP_arch here too?
Hmm, not really, I guess I could add it there as well.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
