[Ffmpeg-devel] Re: [PATCH] Fix compilation when using --disable-opts

[Loren Merritt]

On Sat, 31 Mar 2007, Reimar D?ffinger wrote:
> On Sat, Mar 31, 2007 at 11:01:08PM +0300, Uoti Urpala wrote:
>
>> Your compilation problems might be caused by CONFIG_EBX_AVAILABLE not
>> being set correctly. How are you creating the nonstandard build which
>> uses -fPIC on x86-32? Is that hack done by the Gentoo package by
>> default? Is it done by setting configure flags, and if so, only --cflags
>> or something else?
>
> Not motivated to fix it, but on AMD64 at least with the gentoo package
> PIC has a different problem - somehow MANGLE(ff_h264_lps_range) gets
> substituted to "ff_h264_lps_range(%rip)", which then gets combined to
> something like "movzbl ff_h264_lps_range(%rip)(%rax, %ebx, 2), %esi".
> I guess I should try compiling shared libs from clean source some
> time and see if that's really the problem and how it could be
> fixed/detected...

So how does it work on x86_32? In both archs, pic adds a register offset 
to the address, the only difference is which register (%rip vs %ebx) and 
how it's initialized.
... Looking at the dissasembly of a x86_32 pic build of ffmpeg, it works 
by not actually using pic. e.g. in dsputil_mmx I see a mixture of
     paddw ff_pw_16 at GOTOFF(%ebx), %mm4
and
     movq ff_pw_20, %mm4
depending on whether it's accessed by "m" asm constraint or by MANGLE.

The reason you didn't run into this problem before is that all instances 
of MANGLE in dsputil just refer to a single variable, none of them use any 
complex addressing modes, so appending (%rip) leaves a legal addressing 
mode. The cabac asm was the first usage of MANGLE on an array.



Random side note: Even though %ebx is reserved for pic, gcc is happy to 
use some other register if that generates better code. Since ebx is 
callee-saved, gcc prefers to use a caller-saved reg if there are any free.
example:

static const int bar = 42;
int foo() {
     int x;
     asm volatile("mov %1, %0" :"=r"(x) :"m"(bar));
     return x;
}

08048390 <foo>:
  8048390: call   80483a2 <__i686.get_pc_thunk.dx>
  8048395: add    $0x124b,%edx
  804839b: mov    0xffffef14(%edx),%eax
  80483a1: ret

080483a2 <__i686.get_pc_thunk.dx>:
  80483a2: mov    (%esp),%edx
  80483a5: ret

Furthermore, gcc does let me put ebx on the clobber list if and only if 
none of the inputs to the asm block would use pic (regardless of 
whether ebx is actually being the pic register). So the ebx_available 
check in configure returns true even with pic. Attached patch fixes(?) 
it. I say (?) because ffmpeg compiles and runs even with pic and 
ebx_available. Does it just not encounter the failure case?

(tested with gcc 3.3.5 and 4.1.1 if it matters)

--Loren Merritt
-------------- next part --------------
Index: configure
===================================================================
--- configure	(revision 8578)
+++ configure	(working copy)
@@ -1423,8 +1423,9 @@
 
     # check wether EBX is available on x86
     check_cc <<EOF && enable ebx_available
+static int x;
 int main(){
-    asm volatile ("":::"%ebx");
+    asm volatile (""::"m"(x):"%ebx");
 }
 EOF
 fi