[FFmpeg-devel] [PATCH] fft_tab_neon is not PIC enough
Reimar.Doeffinger at gmx.de
Sun Jul 15 11:04:01 CEST 2012
On 14 Jul 2012, at 17:24, John Reiser <jreiser at bitwagon.com> wrote:
> fft_tab_neon has addresses in .rodata, which is bad for shared libraries.
Could you please be more specific about what exactly "bad" means?
> 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.
This seems extremely brittle to me, especially since I am not aware of a reason why the linker couldn't reorder the functions in whatever way it wants, so the absolute minimum would be supporting an offset that can handle the size of the whole .text segment (or reorganize the code so the linker will not be able to separate it, e.g. by putting everything in a single function, but that is still ugly and brittle).
For other architectures we have solved this problem by storing the difference between a label and the symbols in a table (those will always be real constants), at full 32 or 64 bits and manually add those onto the PC, then jump to the calculated address.
More information about the ffmpeg-devel