[MPlayer-dev-eng] [PATCH] -fPIC support for libswscale
Jason Tackaberry
tack at urandom.ca
Sat Aug 12 17:20:53 CEST 2006
On Sat, 2006-08-12 at 13:40 +0200, Michael Niedermayer wrote:
> have you tried compiling on gcc 2.95, 3.4 and 4.something? thats probably
> a good idea to try as gcc can be fairly picky ...
I've tried with 3.2.3 and 4.0.2 but not yet with 2.95. (But I suppose
if anything is going to give me grief it's going to be 2.95.)
> > {
> > +
> > #ifdef HAVE_MMX
>
> cosmetic change
Yeah, I noticed that after I sent it. Oops.
> > asm volatile(
> > + //"push %%"REG_b" \n\t"
> > "pxor %%mm7, %%mm7 \n\t"
>
> trash
Oops again.
> > - : "%"REG_a, "%"REG_b, "%"REG_c, "%"REG_d, "%"REG_S, "%"REG_D
> > + : "%"REG_a, "%"REG_BP, "%"REG_c, "%"REG_d, "%"REG_S, "%"REG_D
>
> ive a bad feeling about this change, i wont accpet this unless it is tested
> on 2.95,3.4,4.something (test here means the specific piece above must be
> executed and produce a binary identical picture)
> the problem is gcc uses ebp to access "m" if -fomit-frame-pointer isnt used
> (so yes the test MUST NOT use that of course)
Yeah, you're right, without -fomit-frame-pointer it doesn't like the
fact that REG_BP gets clobbered. I could push/pop it, but then I might
as well push/pop ebx. The problem is when I do this (whether it's with
ebx or ebp) I get a segfault when dereferencing the register that has
the location to mmx2FilterPos, and I'm not quite sure why.
Will you accept a patch that builds with -fno-PIC or -fPIC
-fomit-frame-pointer but not -fPIC (without -fomit-frame-pointer)? The
problem is with -fPIC and not -fomit-frame-pointer we have too few free
registers and would require far more mutilation of libswscale than
anyone would be willing to accept.
Jason.
More information about the MPlayer-dev-eng
mailing list