This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposed change: weak symbol support for Darwin
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Mike Stump <mrs at apple dot com>
- Cc: Matt Austern <austern at apple dot com>, Joe Buck <jbuck at synopsys dot com>, GCC list <gcc at gcc dot gnu dot org>, Zack Weinberg <zack at codesourcery dot com>
- Date: Wed, 15 Oct 2003 01:30:17 -0700
- Subject: Re: Proposed change: weak symbol support for Darwin
- Organization: CodeSourcery, LLC
- References: <A7F6B508-FE9D-11D7-9C01-003065A77310@apple.com>
- Reply-to: mark at codesourcery dot com
On Tue, 2003-10-14 at 16:25, Mike Stump wrote:
> On Tuesday, October 14, 2003, at 03:00 PM, Mark Mitchell wrote:
> >> The only reason I was reluctant to make the change globally was that
> >> on most platforms (e.g. Linux/x86) the current scheme ain't broke.
> >
> > For right or wrong, the ABI requires that all vtables with external
> > linkage have "vague linkage". Therefore, I don't think we should
> > change
> > the linkage of vtables on any platform, except those that don't have
> > proper support for weak/COMDAT/etc.
>
> Ok, then I can revise my current patch thusly...
>
> Ok?
! /* We always export if we support weak, but, when weak isn't
supported, we
! only export if the key method isn't redeclared inline. */
That we can see from reading the code -- a better comment would be an
explanation of *why* this is a good idea.
/* If weak symbol support is not available, then we must be
careful not to emit the vtable when the key function is
inline. An inline function can be defined in multiple
translation units. If we were to emit the vtable in
each translation unit containing a definition, we would
get multiple definition errors at link-time. */
But, I don't fully understand how this will work. Will the vtable be
emitted with internal linkage in every translation unit, with your
change? If not, where does the vtable get defined?
I'll assume that it gets internal linkage in every translation unit, and
approve the patch under that assumption, with something like the above
comment in place of the version in your patch.
Thanks,
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC