[FFmpeg-devel] [PATCH] fft_tab_neon is not PIC enough
michaelni at gmx.at
Sun Jul 15 04:47:08 CEST 2012
On Sat, Jul 14, 2012 at 08:24:30AM -0700, John Reiser wrote:
> fft_tab_neon has addresses in .rodata, which is bad for shared libraries.
> Table fft_tab_neon, function ff_fft_calc_neon, in libavcodec/arm/fft_neon.S
> contains addresses but resides in read-only section .rodata.
> The addresses must be relocated whenever the runtime location
> differs from the one that was assumed during static linking.
> This creates a problem for using the code in a shared library.
> The attached patch provides the additional relocation by changing
> the table to an array of branch instructions. The patch also
> checks the bounds of the index. In Thumb mode the 11-bit displacement
> field of a short unconditional branch can span +/- 1024 words
> which is +/- 2048 bytes. By moving the routine to near the middle,
> then the other code could double in size before exceeding
> the limit on span.
> There is a delay of 3 cycles after "add to pc" and 2 cycles
> after the taken 'b'. The total time is similar to previous code,
> which had two pointer fetches, two explicit adds [one missing],
> and a 'bx'. In Thumb mode the array of short branch instructions
> is 30 bytes smaller than the table of addresses.
> The same problem occurs with ff_fft_fixed_calc_neon;
> this patch fixes that problem, too. A similar problem afflicts
> but I have not found those sources. Where are they?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel