[Ffmpeg-devel] Broken trunk on AMD64 with PIC enabled
Tue Apr 3 23:58:33 CEST 2007
On Tue, 3 Apr 2007, Michael Niedermayer wrote:
> On Tue, Apr 03, 2007 at 06:16:10PM +0200, Diego 'Flameeyes' Petten? wrote:
> > /tmp/ccVd770a.s:15722: Error: junk `(%rip)' after expression
> > the code is, for instance:
> > and $0xC0 , %esi
> > movzbl ff_h264_lps_range(%rip)(%eax, %esi, 2), %esi
> > problem seems to come from cabac.h:
> > "andl $0xC0, %%ebx \n\t"
> > "movzbl "MANGLE(ff_h264_lps_range)"(%0, %%ebx, 2), %%esi\n\t"
> > (as far as I can see, %ebx has been replaced with %esi on the output).
Not possible ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Probably came from this code in cabac.h instead:
"and $0xC0 , "range" \n\t"\
"movzbl "MANGLE(ff_h264_lps_range)"("ret", "range", 2), "range" \n\t"\
> add a MANGLE2 without rip and use that where addressing over rip is inpossible
MANGLE uses rip relative addressing for PIC code, but scale-index-base
addressing can't be used at the same time as rip relative. There is
nothing that can be used for "ff_h264_lps_range(%eax, %esi, 2)" that is PIC
for ia32 or x86-64.
I've got to wonder, what the point of MANGLE is? Not a single reference to
MANGLE in cabac.h is going to work in PIC mode, so what's the point of
MANGLE pretending to support pic? This is what I would do:
asm("movzbl %c2(%1, %0, 2), %0"
: "r"(ret), "e"(ff_h264_lps_range));
The 'e' constraint selects a signed 32-bit constant or symbolic reference,
which is exactly what is allowed (for both ia32 and x86-64) for the
displacement field in the address.
gcc will correctly tell you this asm can't be compiled in PIC mode. If you
want PIC, ff_h264_lps_range is not a constant, so you must put it in a
register or not use any addressing modes.
More information about the ffmpeg-devel