[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

[Uoti Urpala]

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.