* [Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
2010-01-21 3:09 [Bug target/42818] New: " davek at gcc dot gnu dot org
@ 2010-01-21 3:20 ` davek at gcc dot gnu dot org
2010-01-21 3:57 ` davek at gcc dot gnu dot org
` (6 subsequent siblings)
7 siblings, 0 replies; 12+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-21 3:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from davek at gcc dot gnu dot org 2010-01-21 03:20 -------
Test results:
clean HEAD@155967, default test configuration using shared C++ linking:
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01628.html
clean HEAD@155967, tested using static C++ linking:
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01900.html
patched HEAD@155967, tested with static linking and the simple stage-3-safe
fix:
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01901.html
--
davek at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2010-01-21 03:20:38
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
2010-01-21 3:09 [Bug target/42818] New: " davek at gcc dot gnu dot org
2010-01-21 3:20 ` [Bug target/42818] " davek at gcc dot gnu dot org
@ 2010-01-21 3:57 ` davek at gcc dot gnu dot org
2010-01-21 4:00 ` davek at gcc dot gnu dot org
` (5 subsequent siblings)
7 siblings, 0 replies; 12+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-21 3:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from davek at gcc dot gnu dot org 2010-01-21 03:57 -------
Here's what's going on:
- To implement operator new/delete replacement, we use ld and --wrap to
redirect all references to the operator functions into redirection stubs in the
cygwin dll.
- Each DLL or executable records a list of which (if any) of those operators it
provides replacements for. It does this with an array of function pointers in
a part of the CRT pre-main() startup. In the array are weak references to all
the replaceable operators; any for which overrides are visible at final-link
time will get filled out with the addresses of those overrides, and the
weakness of the references means they won't cause any functions that aren't
already present in the final link to be pulled in from libraries. The
references assign asm names to the symbols that use the "__real__" prefix in
order that they don't see the Cygwin DLL wrapper functions, just the real
actual implementations present.
- As an optimisation, we don't apply the wrapper redirection when linking
statically. That's because there's no need; any function replacement overrides
present in the final link will just automatically override the libstdc++
versions by preventing them from ever being pulled out of the static libstdc++
archive at final-link time.
That's all fine as it stands, but:-
- Some recent optimisation of EH generation had the effect that, where
previously every C++ object was always emitted with a reference to the gxx eh
personality function, this reference is now only emitted when strictly needed.
- This means that for the first time it became possible that the only
references to libstdc++ in a C++ executable undergoing final link might be
references to the operator new/delete function(s).
- Since these are all redirected to the wrappers in the Cygwin DLL, that can
mean there are no unresolved references to pull in anything at all from the
libstdc++ import library, and so the resulting executable does not depend on
nor cause the libstdc++ dll to be loaded into memory, meaning that the real
versions of the replacement functions that the redirect stubs need to redirect
to aren't present!
- So, the way to prevent that is by also emitting an extern reference to the
real version of the operator function in question, which causes the DLL to be
imported (even though the imports aren't used directly but only via the
redirection stubs in the DLL; the important point being that you have to load
libstdc++ so that it can register the default versions of all the operators
using its own array of weak (but fully-filled-out) function pointers. This is
done in gcc/config/i386/winnt.c, in i386_pe_file_end().
- And that's where it goes wrong. The compiler doesn't know at the time it's
emitting assembly whether the final object will be statically linked or not, so
it really has no choice but to emit the reference; but if it does end up being
statically linked, the wrappers aren't in effect, so there is no "__real__*"
function.
- That wouldn't be a problem: the toolchain doesn't care about the undefined
symbol, because no relocs reference it, and the runtime loader doesn't give a
stuff about symbols at all, caring only about the import and export tables.
- Except for one final gotcha. Because the undefined references that are
emitted to cause the DLL to be loaded are strong undefs - they have to be,
since they have to cause an import stub to be pulled in from a library archive.
So even though there are no relocs in the object that contains the strong
undef, it has the knock-on effect that the weak references in the array of
function pointers become strong. And that's where the link failure arises.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
2010-01-21 3:09 [Bug target/42818] New: " davek at gcc dot gnu dot org
2010-01-21 3:20 ` [Bug target/42818] " davek at gcc dot gnu dot org
2010-01-21 3:57 ` davek at gcc dot gnu dot org
@ 2010-01-21 4:00 ` davek at gcc dot gnu dot org
2010-01-21 4:57 ` davek at gcc dot gnu dot org
` (4 subsequent siblings)
7 siblings, 0 replies; 12+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-21 4:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from davek at gcc dot gnu dot org 2010-01-21 04:00 -------
Created an attachment (id=19670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19670&action=view)
Simple stage-3-safe fix
This is the simple fix that is safe for stage 3. By trivially tweaking the
specs, we remove the don't-redirect-via-wrappers-if-statically-linking
optimisation.
This is a minor performance hit, but correctness combines with the need for
low-risk changes in stage 3 to win out here. I'll talk about the more optimal
fix (and the complications that mean it has to wait for next stage 1) next.
As I've already run all the tests, and as I've just been appointed a
maintainer, I'll check this in shortly :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
2010-01-21 3:09 [Bug target/42818] New: " davek at gcc dot gnu dot org
` (2 preceding siblings ...)
2010-01-21 4:00 ` davek at gcc dot gnu dot org
@ 2010-01-21 4:57 ` davek at gcc dot gnu dot org
2010-01-21 5:00 ` davek at gcc dot gnu dot org
` (3 subsequent siblings)
7 siblings, 0 replies; 12+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-21 4:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from davek at gcc dot gnu dot org 2010-01-21 04:56 -------
Subject: Bug 42818
Author: davek
Date: Thu Jan 21 04:56:38 2010
New Revision: 156105
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156105
Log:
PR target/42818
* config/i386/cygwin.h (CXX_WRAP_SPEC_LIST): Always apply wrappers,
even when linking statically, for now.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cygwin.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
2010-01-21 3:09 [Bug target/42818] New: " davek at gcc dot gnu dot org
` (3 preceding siblings ...)
2010-01-21 4:57 ` davek at gcc dot gnu dot org
@ 2010-01-21 5:00 ` davek at gcc dot gnu dot org
2010-01-21 5:01 ` davek at gcc dot gnu dot org
` (2 subsequent siblings)
7 siblings, 0 replies; 12+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-21 5:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from davek at gcc dot gnu dot org 2010-01-21 05:00 -------
Fixed for 4.5.0, so setting milestone. Then I'll add a comment about the full
fix and suspend it. BZ maintainers, apologies if this is the wrong thing to
do; should I close it and reopen it? I'm not sure, whatever you're happy with
is fine by me.
--
davek at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
2010-01-21 3:09 [Bug target/42818] New: " davek at gcc dot gnu dot org
` (4 preceding siblings ...)
2010-01-21 5:00 ` davek at gcc dot gnu dot org
@ 2010-01-21 5:01 ` davek at gcc dot gnu dot org
2010-04-06 11:26 ` rguenth at gcc dot gnu dot org
2010-07-31 9:35 ` rguenth at gcc dot gnu dot org
7 siblings, 0 replies; 12+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-21 5:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from davek at gcc dot gnu dot org 2010-01-21 05:00 -------
So, the optimal solution would be to avoid using the redirection wrappers when
we're statically linking.
That's still possible: those undefined references without relocs don't cause
problems in and of themselves, but only because they turn the weak undefs that
*do* have relocs strong. The obvious solution, since we're not using the
redirection wrapper functions, is to also not include the array of weak
function pointers.
That would be trival to do by building two different versions of the CRT
startup code in Cygwin itself, one for shared linking that contains the array,
one for static linking that doesn't, and selecting the appropriate one at link
time using a spec in the backend.
That would work fine for --static, but as things stand now, it will still fail
when just --static-libstdc++ is in use. This is because of the situation
described in the two dependency PRs (Bug 41594 and Bug 41596): you can't test
for --static-libstdc++ in a spec, because the code in g++spec.c removes it from
the command-line.
So, I'm going to leave this bug open and suspend it now I've committed the
simple fix. Then, next stage 1, we'll get the situation with
--static-libstdc++ resolved one way or another, and by that time I'll have
added the alternative startup CRT object to the Cygwin runtime, and then I'll
revert this fix and adjust the linker spec to select the correct startup
variant.
--
davek at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
2010-01-21 3:09 [Bug target/42818] New: " davek at gcc dot gnu dot org
` (5 preceding siblings ...)
2010-01-21 5:01 ` davek at gcc dot gnu dot org
@ 2010-04-06 11:26 ` rguenth at gcc dot gnu dot org
2010-07-31 9:35 ` rguenth at gcc dot gnu dot org
7 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-04-06 11:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-06 11:20 -------
GCC 4.5.0 is being released. Deferring to 4.5.1.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.5.0 |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
2010-01-21 3:09 [Bug target/42818] New: " davek at gcc dot gnu dot org
` (6 preceding siblings ...)
2010-04-06 11:26 ` rguenth at gcc dot gnu dot org
@ 2010-07-31 9:35 ` rguenth at gcc dot gnu dot org
7 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-07-31 9:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-31 09:29 -------
GCC 4.5.1 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.5.1 |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
^ permalink raw reply [flat|nested] 12+ messages in thread