[FFmpeg-trac] #272(avcodec:open): altivec specific code segfaults on ppc when compiled with --enable-pic

[FFmpeg]

#272: altivec specific code segfaults on ppc when compiled with --enable-pic
-----------------------+----------------------
Reporter:  kim         |       Owner:
    Type:  defect      |      Status:  open
Priority:  normal      |   Component:  avcodec
 Version:  git-master  |  Resolution:
Keywords:  ppc, PIC    |  Blocked By:
Blocking:              |  Reproduced:  1
Analyzed:  0           |
-----------------------+----------------------

Comment (by kim):

 >what performance effect does this patch have?
 >it could slow things down for cases that dont need the extra code

 Depends on what you mean by 'cases that don't need the extra code'. If you
 compile without PIC, the patch is not used (#ifdef) so no performance loss
 here, and if you compile with -fPIC and a 'recent' gcc nothing works
 anyway (gcc 4.2 which triggers the bug was released in 2007). I can also
 confirm that ASM + patch remains much faster than using the plain C
 version of the function.

 By the way, gcc is using the same trick to load global symbol in -fPIC
 code nowadays:

 {{{
 static int GLOBAL[3] = {1, 2, 3};
 int f(int x) { return GLOBAL[x]; }
 }}}
 Compiling with gcc -O0 -S -c foo.c one can see that the address of GLOBAL
 is computed as so:
 {{{
         bcl 20,31,.L2
 .L2:
         mflr 30
         addis 30,30,.LCTOC1-.L2 at ha
         addi 30,30,.LCTOC1-.L2 at l
 }}}
 where .LCTOC1 is the label marking the begining of the TOC section. This
 is exactly what the patch does.

 Anyway the movrel macro at issue is always followed by *several* memory
 accesses so one extra unconditional jump can hardly impact performances. I
 also belive this patch to be backward compatible so the code can still be
 compiled with older versions of gcc/as (this is untested though).

 What the patch does not handle at the moment is the PPC64 architecture
 (I'm not even sure this arch is affected by this bug).

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/272#comment:14>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker