This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: weak for Darwin



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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]