Bug#493705: libswscale0: The library has text relocations

[Russell Coker]

On Monday 04 August 2008 22:59, Loïc Minier <lool at dooz.org> wrote:
> > The references you provide seem to indicate that the exception is for
> > the case where faster assembly is not available.  IE you have a choice
> > between fast assembly and a slower compiled language.  While if the
> > difference is only 10% (between two different versions of assembly
> > code) then PIC is the way to go.
>
>  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 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.

> > 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.

> > 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.

>  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.