[FFmpeg-devel] Patch: Inline asm fixes for Intel compiler on Windows

[Reimar Döffinger]

On Sun, Dec 29, 2013 at 01:25:05AM +1100, Matt Oliver wrote:
> > More importantly, it actually changes the code.
> > As soon as PIC is enabled, a "m" reference can no longer be stored as a
> > constant.
> > But the code requires it to be a constant.
> > Or to put it simpler: the patch is simply wrong for 32 bit PIC.
> > (and before we start a discussion again: yes, this "hack" means FFmpeg has
> > TEXTRELs in the asm code even for PIC compilation. Since it affects only 32
> > bit I don't consider it very relevant).
> > That said, I also have a very hard time believing that ICC assembler
> > support cannot access global symbols from asm.
> > I find that highly unlikely, more like the MANGLE macro and/or the macros
> > that force these symbols to be exported are not working.
> 
> 
> OK Sorry about the patch not sure what happened there. Im downloading a
> fresh copy of git master that ill use to make up a fresh one.
> 
> As for Intels asm support, on Linux they just use GAS directly for
> compiling all asm. But on Windows they had to implement it themselves and
> so it is incomplete.
> To quote Intel themselves "Direct symbol references in the asm-template are
> not supported. To access a C++ object, use the asm-interface with a
> substitution directive."
> This is from :
> http://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-5100C4FC-BC2F-4E36-943A-120CFFFB4285.htm
> which also lists all the other limitations of inline AT&T asm on Windows.
> 
> So unfortunately there is not really any other option (that I can think of
> anyway). So if using memory "m" constraint cant be used with PIC how would
> you recommend this problem be approached?
> 
> Im happy to allocate the time needed to come up with the ideal solution so
> any input is appreciated.

Well, there is the brute-force approach of using the support for .byte
to define that symbol each and every time it is used.
But that might be more ugly than what we'd want to accept as a patch...