Bug#493705: libswscale0: The library has text relocations

[Loïc Minier]

On Mon, Aug 04, 2008, Russell Coker wrote:
> >  Based on my memory of the discussions, it seemed to me that there is a
> >  performance hit in all cases if you use PIC instead of non-PIC on i386
> >  because a register is used for the relocations;
> 
> It is only a performance hit in cases where you actually need the register.

 I think it's hard to find real CPU bound applications where additional
 registers don't help performance.

> >  I think this impacts 
> >  both assembly and compiled languages, however I could imagine cases
> >  where custom assembly wont build at all if PIC is used (as it might
> >  require more registers than PIC mode provide).
> 
> Custom built assembly can require the extra register, which is what happens 
> with the code in question.  The code does build with PIC, it just happens to 
> not be position independent.  Thus the reserving of a register in all the 
> other code in the shared object has all been wasted.

 Then this is another case; there is custom assembly which wont build at
 all in PIC mode because gcc doesn't have enough registers to offer when
 entering this code and needs to do some relocations.

> > > I expected that the probability of you including my patch to disable the
> > > assembler was low (although a similar patch is in the Fedora tree for
> > > libtheora), but if nothing else it clearly illustrates where the problem
> > > is for anyone who wants to have a go at writing some assembler.
> >
> >  Well, it's interesting to note that Fedora favors SELINUX support
> >  before speed; perhaps something you can bring up in a wider discussion
> >  of this policy decision.
> 
> It's not just SE Linux, it's anything that tries to prevent writable and 
> executable memory.

 Are you suggesting Fedora added the patch for other reasons than
 SELINUX support?  Could you expand on these reasons?

> > > If the performance critical code is going to be handling data from
> > > sources of low integrity (EG playing video downloaded from youtube etc)
> > > then I think that we want all the available security features enabled!
> >
> >  I'm not sure I agree with the rationale; certainly having SELINUX
> >  properly working in apps playing remote contents is a laudable goal,
> >  but I understand SELINUX doesn't make any difference if the libs are
> >  secure already, and we do want the libs to be secure.
> 
> If you care about security then you assume that all code gets broken 
> eventually.  The question is whether you have a safety net when the first 
> layer gets broken or whether you just lose.

 Sure, and if you care about security, you don't connect your computer
 to the internet, or you don't use a computer at all.

 Perhaps we want Debian packages to favor performance, or perhaps we
 want them to favor security features; this decision doesn't belong to
 the two of us but to the project as a whole.

> >  However 
> >  performance is useful in all cases.  So I still think it's a compromise
> >  which needs wider consensus.
> 
> How much performance are we talking about?
> 
> Performance is not of such great use if the system is already fast enough.  If 
> you run a task that performs well on an 800MHz P3 system (such as playing AVI 
> files in 800*600 resolution) on a faster machine (EG any P4 system) then a 
> small amount of performance loss isn't going to be noticed.  In fact in that 
> example you could halve the performance and not notice it!
> 
> #if 1 //is faster only if multiplies are reasonably fast (FIXME figure out on 
> which CPUs this is faster, on Athlon it is slightly faster)
> 
> Also there are comments such as the above near the assembly code.
> 

 I gave pointers on this already; it can be 10%.

-- 
Loïc Minier