[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

[Michael Niedermayer]

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
  at all
* 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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071130/025b9c66/attachment.pgp>