On Sun, 7 Dec 2014, Janne Grunau wrote:
On 2014-11-16 18:13:34 +0200, Martin Storsjö wrote:
---
Using ifdef __linux__ for .data.rel.ro, since we support some
other (ancient) setups which don't support such a section
(in particular, symbian, which still uses elf object files in the
build, but where the toolchain can't handle such a section).
does the assembler fail directly on it? If yes we should add a configure
check instead of using the ifdef __linux__.
No, the assembler doesn't fail directly, but later stages (postlinking)
may fail (or produce unintended results), and I think I also saw the
normal ld linker crash at some point. Not too straightforward to detect at
least.
---
libavcodec/arm/fft_fixed_neon.S | 4 ++--
libavcodec/arm/fft_neon.S | 4 ++--
libavcodec/arm/fft_vfp.S | 4 ++--
libavutil/arm/asm.S | 14 ++++++++++++++
4 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/libavcodec/arm/fft_fixed_neon.S b/libavcodec/arm/fft_fixed_neon.S
index faddc00..a95397b 100644
--- a/libavcodec/arm/fft_fixed_neon.S
+++ b/libavcodec/arm/fft_fixed_neon.S
@@ -242,7 +242,7 @@ function ff_fft_fixed_calc_neon, export=1
bx r3
endfunc
-const fft_fixed_tab_neon
+constrel fft_fixed_tab_neon
.word fft4_neon
.word fft8_neon
.word fft16_neon
@@ -258,4 +258,4 @@ const fft_fixed_tab_neon
.word fft16384_neon
.word fft32768_neon
.word fft65536_neon
-endconst
+endconstrel
diff --git a/libavcodec/arm/fft_neon.S b/libavcodec/arm/fft_neon.S
index c4d8918..7dfed19 100644
--- a/libavcodec/arm/fft_neon.S
+++ b/libavcodec/arm/fft_neon.S
@@ -348,7 +348,7 @@ function ff_fft_permute_neon, export=1
pop {r4,pc}
endfunc
-const fft_tab_neon
+constrel fft_tab_neon
.word fft4_neon
.word fft8_neon
.word fft16_neon
@@ -364,7 +364,7 @@ const fft_tab_neon
.word fft16384_neon
.word fft32768_neon
.word fft65536_neon
-endconst
+endconstrel
const pmmp, align=4
.float +1.0, -1.0, -1.0, +1.0
diff --git a/libavcodec/arm/fft_vfp.S b/libavcodec/arm/fft_vfp.S
index 9c7b54e..704e3ef 100644
--- a/libavcodec/arm/fft_vfp.S
+++ b/libavcodec/arm/fft_vfp.S
@@ -33,7 +33,7 @@ function ff_fft_calc_vfp, export=1
movrel a2, (fft_tab_vfp - 8)
ldr pc, [a2, ip, lsl #2]
endfunc
-const fft_tab_vfp
+constrel fft_tab_vfp
.word fft4_vfp
.word fft8_vfp
.word X(ff_fft16_vfp) @ this one alone is exported
@@ -49,7 +49,7 @@ const fft_tab_vfp
.word fft16384_vfp
.word fft32768_vfp
.word fft65536_vfp
-endconst
+endconstrel
function fft4_vfp
vldr d0, [a1, #0*2*4] @ s0,s1 = z[0]
diff --git a/libavutil/arm/asm.S b/libavutil/arm/asm.S
index 93d74b6..ce368cb 100644
--- a/libavutil/arm/asm.S
+++ b/libavutil/arm/asm.S
@@ -99,6 +99,20 @@ ELF .size \name, . - \name
\name:
.endm
+.macro constrel name, align=2
+ .macro endconstrel
+ELF .size \name, . - \name
+ .purgem endconstrel
+ .endm
+#ifdef __linux__
+ .section .data.rel.ro
+#else
+ .section .rodata
+#endif
+ .align \align
+\name:
+.endm
did you consider adding a relocable variable to the const macro?
That would make things a bit nicer indeed
With a HAVE_SECTION_DATA_REL_RO 0/1 define from configure the const
macro could look like
That would look quite nice - at worst we could set this HAVE_* manually in
configure if we don't have any usable detection.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
