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