This is the mail archive of the
mailing list for the GCC project.
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 23 Mar 2013 00:41:32 +0000
- Subject: Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
- References: <CAEwic4Y5mMhokud4T-ZtA3GAHeWiQsGXfq=goo-2fj9Qm3GHSA at mail dot gmail dot com> <514CF02C dot 5070707 at gmail dot com> <CAEwic4axt7sKSVpmyqX2YBzdfjxNx956tacVcOE6-f06T5CUAA at mail dot gmail dot com> <514CF60B dot 2020806 at gmail dot com> <CAEwic4Ygnw7Uh+pGHvpM+y2MLDjG1Qf+mvwCDae_-d3OCKNmZw at mail dot gmail dot com>
On 23/03/2013 00:27, Kai Tietz wrote:
> 2013/3/23 Dave Korn <email@example.com>:
>> On 23/03/2013 00:08, Kai Tietz wrote:
>>> 2013/3/23 Dave Korn <firstname.lastname@example.org>:
>>>> Also, can you explain the motivation for this change? I don't see how it's
>>>> going to work right; from what I remember, we don't have weak definitions in
>>>> PE-COFF, just weak references. How does the correct definition get chosen
>>>> when we may have two definitions in a final link?
>>> Well, weak undefs are possible with pe-coff. We ran into that by
>>> porting cygwin to x64.
>>> But you are right that pe-coff doesn't support undefines (weak or
>>> none-weak) within final-link, so for a weak we need always a default
>>> implementation. This we added here.
>> I thought it does (support weak undefines within final link). Weak
>> references with no definition resolve to zero, no?
> No, actual they aren't zero value, they are reported as undefined
> symbol, which seems to me from perpective of pe-coff weak definition
> the right thing to do.
I think something's going wrong. From the PE-COFF specs:
> “Weak externals” are a mechanism for object files that allows flexibility
> at link time. A module can contain an unresolved external symbol (sym1),
> but it can also include an auxiliary record that indicates that if sym1 is
> not present at link time, another external symbol (sym2) is used to resolve
> references instead. If a definition of sym1 is linked, then an external
> reference to the symbol is resolved normally. If a definition of sym1 is
> not linked, then all references to the weak external for sym1 refer to sym2
> instead. The external symbol, sym2, must always be linked; typically, it is
> defined in the module that contains the weak reference to sym1.
In gcc/binutils, what we do is automatically provide an aux record (sym2)
with the value *ABS* zero. If a definition (strong, because we only have
strong definitions in PE-COFF) of the weakly-referenced symbol is provided,
that overrides the aux value of zero, but otherwise the zero value is used.
IIRC, there's a binutils bugzilla entry about things not going well if two
strong definitions are provided to resolve a weak external. I'll try and dig