Discussion:
[PATCH] arm: Suppress tags about used cpu arch and extensions
(too old to reply)
Martin Storsjö
2015-02-17 22:44:14 UTC
Permalink
When all the codepaths using manually set .arch/.fpu code is
behind runtime detection, the elf attributes should be suppressed.

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.
---
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

#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
#endif
--
1.7.10.4
Luca Barbato
2015-02-18 03:02:55 UTC
Permalink
Post by Martin Storsjö
When all the codepaths using manually set .arch/.fpu code is
behind runtime detection, the elf attributes should be suppressed.
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.
Do we support them?

lu
Martin Storsjö
2015-02-18 11:07:19 UTC
Permalink
Post by Luca Barbato
Post by Martin Storsjö
When all the codepaths using manually set .arch/.fpu code is
behind runtime detection, the elf attributes should be suppressed.
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.
Do we support them?
I don't know actually - Derek has tried freebsd on arm at least, but dunno
if he tried running our asm. Symbian also builds as ELF (but then is run
through a separate post-linker that rips out the linked data and packages
it into the symbian executable format). In any case, adding these (as long
as the assembler supports them) shouldn't really hurt much for those
cases, they just don't get tagged correctly as containing NEON/VFPv3 code.

Janne, opinions?

// Martin
Janne Grunau
2015-02-21 22:09:08 UTC
Permalink
Post by Martin Storsjö
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.
Post by Martin Storsjö
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.
Post by Martin Storsjö
---
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?
Post by Martin Storsjö
#if HAVE_NEON
.fpu neon
#elif HAVE_VFP
.fpu vfp
Any reason not to suppress Tag_FP_arch here too?

Janne
Martin Storsjö
2015-02-21 22:16:07 UTC
Permalink
Post by Janne Grunau
Post by Martin Storsjö
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.
Post by Janne Grunau
Post by Martin Storsjö
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.
Post by Janne Grunau
Post by Martin Storsjö
---
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.
Post by Janne Grunau
Post by Martin Storsjö
#if HAVE_NEON
.fpu neon
#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
Janne Grunau
2015-02-21 22:20:35 UTC
Permalink
Post by Martin Storsjö
Post by Janne Grunau
Post by Martin Storsjö
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.
Yes, that was my complicated way of saying that there should be no
function without runtime detection in .S
Post by Martin Storsjö
Post by Janne Grunau
Post by Martin Storsjö
+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?
I'll do tomorrow. In the worst case we have to add it to gaspp since it
still can't assemble other bits.

Janne

Loading...