This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Updated version of x86_64-pc-mingw32 support of gcc.
- From: Kai Tietz <Kai dot Tietz at onevision dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: bonzini at gnu dot org, gcc-patches at gcc dot gnu dot org, Jan Hubicka <hubicka at ucw dot cz>
- Date: Mon, 19 Mar 2007 17:45:49 +0100
- Subject: Re: PATCH: Updated version of x86_64-pc-mingw32 support of gcc.
Michael Matz <matz@suse.de> wrote on 19.03.2007 17:34:18:
> > Reasoned by the RVA relocation, which is 64-bit, it is necessary for
> > sure. As rev. see the msvcrt.dll, where it's base loading address is
> > placed.
>
> Hmm, I've forgotten most about PE, so you might be right. But as you
have
> PC relative addressing the difference between %rip and any data from the
> same module is never larger than 2GB --> small model is enough. If you
> can encode addresses of module X directly in .text of module Y, only
then
> you need the large model. You generally really really want to avoid
using
> it, e.g. by indirecting over a pointer holding that 64bit address, but
> placed in .data (or GOT in ELF), and loading from it, instead of
encoding
> that 64bit address directly into .text.
>
See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win64/win64/introducing_64_bit_windows.asp
for more information. If gcc would produce rip code (really position
idepent code), than may the relocation issue could be ignored. 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.
Cheers,
i.A. Kai Tietz