PATCH: Updated version of x86_64-pc-mingw32 support of gcc.

[Ross Ridge]

Kai Tietz writes:
> If gcc would produce rip code (really position idepent code), than
>may the relocation issue could be ignored.

GCC can produce RIP relative code.  That what it does when using
the x86_64 SysV ABI small model.  This isn't the same things position
indepedent code (PIC) and Windows does not support ELF-style PIC.  There's
no provision for the global object table (GOT) necessary to make PIC work.

>But gcc doesn't do that, eg. for string-constants on passing them to
>functions as e.g. printf. An absolute reference is getting produced by
>pushing its address, which leads for PE to an RVA relocation.

If you mean it's generating a 64-bit offset, this is only a problem in so
much a GCC is generating less than optimal code.  It doesn't mean that
Windows requires or should be using a large code model.  Since images
are limitted to a 2G range of address space, GCC can and should use a
small code model.  However, the small code model that Windows uses is
not the same as any of the three small code models defined in the x86_64
SysV ABI (executable, kernel and PIC).  It's its own model, that uses
RIP relative addressing, but doesn't make assumptions on where images
are loaded and doesn't require PIC.

So in other words, you need add a CM_SMALL_MS model to GCC.  When
compiling code using the x64 Windows "ABI" this should be the default,
and specifying any other code model should either be ignored or generate
error.  Similarly specifying PIC flag should either be ignored or generate
an error.  (Actually, the CM_SMALL model might work for code that is
known to only be used in executables, but allowing it as an option at
this point is probably not a good idea.)

						Ross Ridge