Re: weak for Darwin

["Aaron W. LaFramboise" <aaronavay62 at aaronwl dot com>]

Geoffrey Keating wrote:

> "Aaron W. LaFramboise" <aaronavay62@aaronwl.com> writes:
> 
> 
>>>	* libsupc++/new_op.cc (new): Make weak.
> 
> 
>>The reason I'm asking is that I think this change will break non-ELF
>>targets where weak symbols are translation-unit local (that is, weak
>>symbols have meaning #2, but not meaning #1).  One such binary format is
>>PECOFF, and I think there are others that have similar semantics.
> 
> Could you describe the nature of the breakage you'd expect?  I would
> imagine such targets will quietly ignore the 'weak' (just like Darwin
> does with weak_import), so that you can do

To clarify, on some targets, such as PECOFF, weak symbols are not
external.  By changing the definition of operator delete to weak, it is
no longer an external symbol, and references to it will be undefined in
the final link, causing failures of all nontrivial C++ programs.  (See
<http://gcc.gnu.org/ml/gcc-testresults/2004-10/msg01513.html>, where
this change caused 500 testsuite failures for a weak-enabled
i686-pc-mingw32 build.)

On PE targets in particular, the separate meaning of external symbols
that are "overridable" is not handled by the same weak mechanism as in
ELF, but with COMDAT.  I think ELF recently also got some sort of
support for COMDAT.  (Confusingly, some of the comments in libstdc++-v3
refer to this separate mechanism as "weak symbols," even though it
really isn't.  Its probably closer to "weak sections.")

I admit I still don't entirely understand why adding weak is an
optimization for your loader.  It seems, though, that you're adding
'weak' not because you want the symbol to be weak, but to take advantage
of some special Darwin-specific semantics of weak symbols that ELF and
other traditional weak symbols don't have.  Would it be possible to
conditionalize the 'weak' part on a Darwin or Mach-O target?

> void foo(void) __attribute__((weak));
>
> in a header, and then actually include that header when defining foo.

No, I guess this won't work on PECOFF targets, due to their
translation-unit local meaning.  Usually this isn't a problem, though,
because if a function is prototyped in a header, it practically has to
be defined anyway (unless we want users to check if the function is null
before calling it, would be an evil interface), and so theres no real
value in weakening the declaration in a header even for those targets
that have undefined weak symbols with external linkage.


Aaron W. LaFramboise