[FFmpeg-devel] ARM-NEON patches

[Pavel Pavlov]

> >> From: ffmpeg-devel-bounces at mplayerhq.hu [mailto:ffmpeg-devel-
> >> bounces at mplayerhq.hu] On Behalf Of Reimar D?ffinger
> >> Sent: Wednesday, July 07, 2010 16:04
> >> To: FFmpeg development discussions and patches
> >> Subject: Re: [FFmpeg-devel] ARM-NEON patches
> >>
> >> On Wed, Jul 07, 2010 at 03:34:52PM -0400, Pavel Pavlov wrote:
> >> > How does movw/movt work on elf with function addresses?
> >>
> >> I'd guess the same way it works with every other address?
> >> Fixing it up at load time?
> >
> >
> >
> > Well, I asked about that because I didn't think that loader actually modifies
> executable code itself.
> > On windows, there is an import table (function pointers) and at load time
> this pointers are set with function addresses. All the code is simply copied as-
> is from file to memory. That's how I always thought it works.
> 
> Usually, but not always... there's a process called rebasing which runs if a DLL
> can't load at its preferred address.  See
> http://blogs.msdn.com/b/larryosterman/archive/2004/07/06/174516.aspx .
> 
> -Eli



Yes, that's true. Executable generally do not have relocatable symbols table, but the dlls do have.
Winnt.h has these constants for relocatable symbols: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_LOW. Seems that these are the ones that should be used for movw/movt pairs. But that's probably should be implemented by binutils (if these IMAGE_REL_BASED_HIGH and IMAGE_REL_BASED_LOW are handled by the os loader at all). Anyways, gnu assembler complains that movt/movw relocations cannot be represented in coff object format.