This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: 64bit: weak symbols
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 09 Apr 2013 07:02:04 +0100
- Subject: Re: 64bit: weak symbols
- References: <CAGvSfez95-FqQ+pLT7MWqYahwqSAWB9v3guHsKfLuj=Jy8r8FQ at mail dot gmail dot com> <20130331103208 dot GG11950 at calimero dot vinschen dot de> <265058237 dot 570397 dot 1364893537242 dot JavaMail dot root at redhat dot com>
On 02/04/2013 10:05, Kai Tietz wrote:
> This issue is a bit tricky. The only way to solve this for 64-bit is by
> making weak-symbols always using indirect access. The issue is that
> symbols for x64 are pc-relative in instructions. So a NULL-address isn't
> necessarily possible for an image-base >2GB as address because
> instruction-relocations are 32-bit signed. By using indirect-access (as
> done for large-code-model also for functions) an absolute symbol to
> zero-address would be possible. One weakness I see about this approach
> because the extern symbol is just known to be weak in the TU(s) where it is
> prototyped as external weak-symbol. Otherwise it is treated as a standard
> symbol and for none-large-code-model a direct pc-relative-addressing is
> used. So I would suggest to use instead here only none-external
> weak-symbols. Means that the a weak-implementation is provided which might
> get overriden by a none-weak implementation on link. This is the way I
> used for the crtbegin.c patch I posted to gcc's ML, where Dave was
> commenting to.
>
> Dave said that he wanted to look into that, so I would like to hear his
> findings about that subject.
Thanks for the explanation Kai, I wasn't aware of the problems w.r.t 64-bit
vs. memory models. I've replied over on the gcc-patches list, agreeing that
the patch is ok. (I suggested a couple of minor changes in formatting and no
longer testing the function pointers for NULL).
cheers,
DaveK