[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