[x264-devel] x86: eliminate text relocation in asm

Henrik Gramner henrik at gramner.com
Wed Mar 16 17:45:00 CET 2016


On Wed, Mar 16, 2016 at 1:24 PM, Jean-Philippe Jodoin
<jpjodoin at summit-tech.ca> wrote:
> Hello,
> I see that the x264 library was patched to support Android API 23 (Android 6)  on ARM by removing text relocation .
> https://mailman.videolan.org/pipermail/x264-devel/2015-October/011479.html
>
>  It works fine on ARM but when I try to compile on x86 for Android, I have the same issue (Android 6 will refuse to link it because of text relocation).
>
> I use this configure command:
>
> ./configure --host=i686-linux-android
> --cross-prefix=C:/android-ndk-r9d/toolchains/x86-4.6/prebuilt/windows-x86_64/bin/i686-linux-android
> --sysroot=C:/android-ndk-r9d/platforms/android-14/arch-x86
> --disable-cli
> --enable-shared
> --disable-opencl
> --enable-pic
>
> My understanding is that --enable-pic prevents text relocation in the C code, but there is still some hardcoded in the x86 ASM code.
> Using scanelf -T, I see what seems to be 1030 text relocations with the current master branch.
>
> Is there any way to fix this issue ?
>
> Thanks,
>
> Jean-Philippe

Hi

There is no way of "fixing" it on our side aside from rewriting
>20.000 lines of handwritten assembly since 32-bit x86 doesn't support
instruction-pointer-relative addressing. x86-64 has RIP-relative
addressing so it shouldn't be an issue there, the same goes for ARM. A
"workaround" is to disable asm on 32-bit x86 but it obliterates
performance and makes x264 painfully slow.

The fact that some Google engineer on a whim decided to arbitrarily
break user space for no good reason by forbidding relocations is
absolutely ridiculous and it affects many other software projects
(such as FFmpeg/libav) as well.

The only real benefits of PIC on 32-bit x86 is a few milliseconds
faster startup time and very slightly reduced memory usage when
running multiple instances of the same library at the same time, but
it also makes the code base a lot more complex and harder to maintain,
increases code size, and makes everything run slower.

Henrik


More information about the x264-devel mailing list