64bit: weak symbols

[Dave Korn]

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