weak for Darwin

Geoff Keating geoffk@geoffk.org
Mon Nov 1 20:32:00 GMT 2004


On 01/11/2004, at 11:21 AM, Aaron W. LaFramboise wrote:

> 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.

I am not sure what this means.

You said that PECOFF gives weak symbols meaning #2:

>>  2. Applied to a symbol that isn't defined in the current translation 
>> unit it makes a weak undefined symbol (i.e. one whose address must be 
>> tested before the symbol is used, because at runtime it may or may 
>> not have a definition).

How can something be 'not external' and yet not 'defined in the current 
translation unit' either?  Is weak on PECOFF just a way of saying "this 
symbol is NULL"?

>   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's not an optimisation.  It assures correct semantics while 
permitting an optimisation.

>   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.

I really do want the semantics of 'weak' as on ELF.  In particular, I 
want the property that:

>>  1. Applied to a symbol that's defined in the current translation 
>> unit, it makes it a weak definition. (i.e. one that can be overridden 
>> by a strong definition elsewhere).


>   Would it be possible to conditionalize the 'weak' part on a Darwin 
> or Mach-O target?

It would be possible to have PECOFF disable the weak-ness using a macro.

>> 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.

The whole point of meaning #2 is that you would test if the function is 
null before calling it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2410 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20041101/47b76adb/attachment.p7s>


More information about the Libstdc++ mailing list