Well, yes and no.
In general what you state is quite true.
But there are always strange applications, and Avaya has one, where a
final executable is really a "merge" of what used to be independent
processes, with methods that also shared the same name, and data
structures and heaps that shared the same name. We employ an in-house
tool to "munge" the clashing symbols before finally linking the merged
executable, and then "un-munge" the symbols back, so that the final
executable *CAN* have multiple definitions of the same symbol names.
Taking away the "-fno-weak" would make this quite painful to do with
template class instantiations, and we may have to resort to other
trickery like "munging" the "-S" assembly code generated to remove the
".weak" directives before generating the .o's.
Is there anything in the C++ standard or ABI that dictates that template
class instantiations emit weak aliases for methods? I would seriously
doubt that since weak aliases are an ELF only manifest, aren't they?
Thanks
- Bhavesh
Bhavesh P. Davda | Distinguished Member of Technical Staff |
Avaya | 1300 West 120th Avenue | B3-B03 | Westminster, CO 80234, U.S.A.
| Voice/Fax: (303) 538-4438 | [EMAIL PROTECTED]
-----Original Message-----
From: Daniel Jacobowitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 23, 2005 2:40 PM
To: Davda, Bhavesh P (Bhavesh)
Cc: gcc@gcc.gnu.org
Subject: Re: C++ -fno-weak with template instantiations
On Wed, Feb 23, 2005 at 02:33:33PM -0700, Davda, Bhavesh P (Bhavesh)
wrote:
> The documentation for "-fno-weak" still states that:
>
> Do not use weak symbol support, even if it is provided by the linker.
> By default, G++ will use weak symbols if they are available. This
> option exists only for testing, and should not be used by end-users;
> it will result in inferior code and has no benefits. This option may
> be removed in a future release of G++.
>
> However, this option is indispensible when generating relocatable
> objects (ld -r) which need to have "strong" definitions of template
> class method instantiations so that they bind to the right symbols
> local to the relocatable object when finally linked into an
> executable.
>
> Are there any plans to remove "-fno-weak"? If so, please consider this
> case as a valuable user of this feature.
That sounds like a reason to remove it; I'm not sure quite what you're
doing, but it's far outside the normal semantics of weak and strong
symbols. You can't have two copies of a strong definition in an
executable, so binding to the "right" one is never an issue. And the
point of the mangling is that the two should be interchangeable anyway.
--
Daniel Jacobowitz
CodeSourcery, LLC
