[FFmpeg-devel] Question about -fPIC usage for some files
Sun Feb 10 05:09:21 CET 2008
On Sat, Feb 09, 2008 at 07:23:41PM -0800, Trent Piepho wrote:
> On Fri, 8 Feb 2008, Michael Niedermayer wrote:
> > On Fri, Feb 08, 2008 at 01:03:56PM -0800, Trent Piepho wrote:
> > > On Fri, 8 Feb 2008, Thorsten Jordan wrote:
> > > > > Why does it fail with pic for you?
> > > > the same problem that was discussed several times on this list, gcc
> > > > fails to generate the code because it runs out of registers (ebx is used
> > > > with -fPIC):
> > >
> > > Since version 3 something, gcc can use other registers besides ebx, and
> > > might not use ebx at all if the function doesn't do anything that requires
> > > access to the pic pointer. If a function accesses no globals, does not
> > > take the address of a fuction, or call a function in another shared
> > > library, it shouldn't need to load the pic register.
> > >
> > > The real problem isn't ebx, it's accessing globals. In non-PIC code, a
> > > memory reference to a global takes zero registers. In PIC code, it takes
> > > one register. In some cases multiple global references can share the same
> > > register(s), so gcc doesn't always need one per global. But this could
> > > still easily add a half dozen extra registers to an asm block.
> > Lets look at the actual code that fails:
> > :"+&r"(i), "=m"(autoc[j]), "=m"(autoc[j+1]), "=m"(autoc[j+2])
> > :"r"(data1+len), "r"(data1+len-j), "m"(*ff_pd_1)
> There aren't always going to be 8 registers.
Well every x86 system ive seen had at least 8. If you have one with less
iam very interrested in that. But i dont think theres any software around
which will run on that :)
> First of all, esp isn't a
> general purpose register on x86.
Which instruction doesnt support esp?
> It's also somewhat problematic to save
> and restore esp in a thread safe manner
> or receive signals with an invalid
An OS not switching stacks for signals, interrupts, ... is broken
even windows did this >10 years ago
> Regardless of why, gcc doesn't support esp as a general register.
> So that leaves 7.
yes, and that would still be enough ...
> If the frame pointer is turned on, gcc doesn't support saving and restoring
> that either.
bug in the gnu c compiler
> That would complicate stack traces in debugging, and if
bug in the gnu debugger, also the frame pointer was turned off IIRC
> you're not interested in that, you can always turn the frame pointer off.
> So that might leave 6.
> If gcc needs a pic pointer for the function, that takes another register.
gcc bug, hint hint: push ebx ... pop ebx
> I'm pretty sure gcc isn't able to flush and restore the pic pointer. And
yes, i think so too, ive never seen gcc do that, though i did see gcc
sometimes using the pic register for asm anyway. It just tended to crash
5 instrictions later most of the time. I think that has been fixed though
PS: no iam not really disagreeing with you on any point. I just cant take
this joke of a compiler serious ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel