[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