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. > 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. > --- > 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? > #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? Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
