Re: [libdv-dev] Re: libdv for AMD64

[Roman S. <rv...@su...>]

On Wed, Dec 08, 2004 at 03:34:24AM -0700, Dean Kolosiek wrote:
> I'm pretty sure R_X86_64_PC32 is correct for 64 bit PIC code. In fact, I 
> had to change these same instructions, the ones with (%rip), to get it to 
> link on my machine. I was getting the same error message, but for 
> R_X86_64_32S.
> 
> I'm new to libtool, so I can't help if that's the problem.
> 
> I think -fPIC is for the compiler to generate position independent code, 
> and won't affect the assembler.
> 
> I'm using Fedora Core 2 x86-64, gcc 3.3.3, ld 2.15.90.0.3, libtool 1.5.6
> 
> All I can think of now is that the linker is confused, as if it thinks it 
> is linking 32 bit code or something, or too old to handle R_X86_64_PC32 . 
> 32 bit code used a different relocation mode.

  We have the very same issue if ffmpeg. Here's my evaluation of the problem:

===============================================================================
From: Roman Shaposhnik
To: ffmpeg-devel
Subject: AMD64 build

On Fri, Nov 05, 2004 at 04:02:57PM -0800, klsat17 wrote:
> Hey guys,
> 
> I searched the archives for this problem, but couldn't find that anyone has 
> run across it.   After running 
> ./configure --with-x11libdir=/usr/X11R6/lib64/ --libdir=/usr/lib64 
> --enable-shared
> 
> and then typing make, I get the error listed below.  I'm a newbie when it 
> comes to this whole I-want-to-copy-DVDs effort and have discovered so many 
> different packages and libraries which must be installed that I am 
> particularly confused.  I also compiled and installed the xvidcore-1.0.2 
> (with the -fPIC flag) package separately.  With regard to the -fPIC stuff, I 
> tried forcing this as a CFLAG, but it doesn't seem to make any difference.  
> Can anyone shed any light on this?  

  -fPIC lets you cure the original problem (the one you quoted) but
  it leaves you in the open with the problems in the following three
  files:
        i386/simple_idct_mmx.o
	i386/motion_est_mmx.o
	i386/dsputil_mmx.o

  And this really opens the floodgate for the usual "bash-the-gcc" sort
  of feast. Here's the deal, take a look at this code:

  $ cat test.c
  static const uint64_t ff_pw_3 __attribute__ ((aligned(8))) = 0x0003000300030003ULL;
  void bar (void)
  {
    asm ("pmullw ff_pw_3, %%mm5" ::);
  }

  Now, when this code gets compiled on x86, it generates the usual relocation
  of R_386_32 for the ff_pw_3 symbol and later, since this symbol is local
  anyway, linker happily accepts R_386_32 and patches the real offset in.

  Now, when compiled on AMD64 it generates R_X86_64_PC32 relocation
  which seem like the right thing to do, but later linker gets confused
  and doesn't want to patch the real offset in. It is not clear to me
  why the confusion. AFAIK, in this particular case (and especially
  given the absence of the large model) R_X86_64_PC32 should behave
  exactly like R_386_32 does on x86. All in all, it seems to be 
  a linker bug to me.

  Once again -- this is not an issue of *creating* a .text relocation
  in a shared library, but simply an issue of accepting R_X86_64_PC32
  on input, being smart enough to see that we *DO NOT* actually need a 
  relocation and outputting the absolute address into the .so.

  Now, the fact tha GNU ld doesn't want to accept R_X86_64_PC32
  even if there's no need to generate any actual relocation made
  gcc guys *forbid* it when you specify -fPIC (once again, I *DO*
  think this is totally uncalled for, but lets put that aside
  for a moment here). Of course they have no control over the
  verbatim stuff you put in your __asm__ ... hence you need
  to be more specific:
  
  static const uint64_t ff_pw_3 __attribute__ ((aligned(8))) = 0x0003000300030003ULL;
  void bar (void)
  {
    asm ("pmullw %0, %%mm5" : : "m" (ff_pw_3));
  }
 
  And that compiles right of the bat:

  $ cc -shared -fPIC -o test.so test.c
  $ 

  Of course it generates one extra instruction:

      lea .... , %rax
      pmullw (%rax), %mm5

  but that's a different story.

  So, what does it mean for ffmpeg ? Well, at this point I'd rather ask GNU ld
  folks about why ld is not smart enough to recognize this situation.
      
Thanks,
Roman.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Ffmpeg-user mailing list
Ffm...@li...
https://lists.sourceforge.net/lists/listinfo/ffmpeg-user
===============================================================================