Bug#493705: libswscale0: The library has text relocations
lool at dooz.org
Mon Aug 4 14:21:52 UTC 2008
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%.
More information about the pkg-multimedia-maintainers