[FFmpeg-devel] [FFmpeg-cvslog] r11100 - in trunk/libavcodec/i386: cavsdsp_mmx.c dsputil_mmx.c dsputil_mmx.h h264dsp_mmx.c mpegvideo_mmx.c vc1dsp_mmx.c
Fri Nov 30 21:11:12 CET 2007
On Fri, Nov 30, 2007 at 07:04:42PM +0200, Uoti Urpala wrote:
> On Fri, 2007-11-30 at 12:26 +0100, Michael Niedermayer wrote:
> > On Thu, Nov 29, 2007 at 03:53:47PM -0700, Loren Merritt wrote:
> > > (1) static (like it was before)
> > > (2) #pragma GCC visibility ...
> > > (3) ld -Bsymbolic
> > > (4) ld --version-script ...
> > > (5) implement full PIC access (double deference, not just rip-relative).
> > >
> > > (2) obvisouly requires gcc. (3) and (4) require GNU ld. (5) makes the
> > > shared library slower (I have no idea how much).
> Would (3) or (4) actually fix compilation in this case? I think the
> addressing mode generated by the compiler causes the problems and AFAIK
> the linker wouldn't change that.
ive not tested it (no x86-64 here) but if loren says it solves the problem
then iam sure it does
the way i understand it is that
* the x86-64 does not support displacement offsets >32bit
* the toolchain seems to be designed around the idea that there are more
than 4gb of shared libs on your system but that a single lib would be less
than 4gb (and the hardware cant handle that with normal addressing)
* the default is that all non static symbols are overrideable at
runtime (which means they could be overridden from libs which are outside
the reachable 4gb window in theory)
the obvious solutions would be
* dont use RIP relative addressing but build the address with several
instructions for non static stuff (this is what
ulrich dropper and his lemmings seem to want) obviously this would
cause a huge speed loss
* use 64bit addressing, this would need relocations and thus reduce the
sharing oppertunities also i dont know if the toolchain can handle this
* live with having less than 4gb of your memory used by shared libs
(and fix the toolchain and maybe kernel to handle this properly)
* dont have your stuff overrideable by default (which is silly anyway)
summary, its cause by MANY stupid and wrong design decissions ...
> > id accept a patch with (3) as well as (1) and reject (5) dunno about the
> > others
> > also i suspect (3) could lead to some speedups for shared libs ...
> Any linker stuff like (3) or (4) cannot give the full available speedup;
yes, but adding -Bsymbolic to ld is easy, getting the vissibility correct
migh not be, i dunno, iam happy with a clean patch which fixes the vissibility
of symbols to the minimum overrideable and vissible as well
still i think (3) is simpler ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel