[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
Rich Felker
dalias
Sun Dec 2 20:26:46 CET 2007
On Sun, Dec 02, 2007 at 12:44:38AM +0200, Uoti Urpala wrote:
> On Sat, 2007-12-01 at 15:00 -0700, Loren Merritt wrote:
> > On Sat, 1 Dec 2007, Uoti Urpala wrote:
> > > On Sat, 2007-12-01 at 11:57 -0700, Loren Merritt wrote:
> > >> AFAICT, x264's visibility situation is very simple: One pragma in x264.h
> > >> to mark the api as public, and gcc -fvisibility to mark everything else as
> > >> hidden.
> > >
> > > That'll mark all the symbols hidden, but the generated code still won't
> > > access them directly except those defined in the same translation unit.
> >
> > Then -fvisibility works for functions (hidden functions get resolved at
> > link time even without -Bsymbolic). Only nonstatic global data needs
> > visibility info in the declaration. And x264 doesn't use nonstatic global
>
> Not true on 32-bit at least (the functions do get resolved, but the code
> still uses the less efficient access method). Consider the following
> file:
> ----
> __attribute__((visibility("hidden"))) int e1(void);
> int e2(void);
> int f1(void) { return e1(); }
> int f2(void) { return e2(); }
> ----
>
> compiling with "gcc-4.2 -fomit-frame-pointer -O3 -fPIC -S" gives the the
> following code for f1 and f2:
>
> f1:
> jmp e1
>
> f2:
> pushl %ebx
> call __i686.get_pc_thunk.bx
> addl $_GLOBAL_OFFSET_TABLE_, %ebx
> subl $8, %esp
> call e2 at PLT
> addl $8, %esp
> popl %ebx
> ret
>
> -fvisibility makes no difference as it cannot affect the external
> declaration for e2, and the linker cannot change the already generated
> code for f2.
Well this is gcc being idiotic. There is absolutely no reason for a
PIC function call to look any different from a non-PIC one to the
caller. The fixup belongs entirely in the PLT. The call and jmp
instructions are already eip-relative and the location of the PLT
relative to the function is known at linktime.
Rich
More information about the ffmpeg-devel
mailing list