Odd ld behaviour starting at version 2.22
Hello,
I'm not actually sure that this is a linker bug, but it sure looks
like one. Version 2.21.1a of ld works fine, but starting at version
2.22 and up to 2.24, we are seeing some odd behaviour that is hard to
pin down. All versions of the linker were built and run on a x86_64
RHEL 6.4 system specifying only --prefix to configure. The symptoms vary,
but one symptom that seems to turn up a lot in many different unit tests
is that we have a hashmap
typedef hash_map tmomap_t;
tmomap_t TmoMap;
defined at file scope. In at least one of the unit tests that fail, nothing
is ever put into this hashmap, yet the shutdown loop iterates at least once:
for (tmomap_t::const_iterator it = TmoMap.begin(); it !=
TmoMap.end(); ++it)
{
if (it->second.state == FIRED) continue;
union SIGNAL* sig = it->second.tmosig;
if (sig) free_buf(&sig);
}
Here the symptoms seems to vary. Sometimes we get a crash when "it"
is dereferenced, and sometimes the call to free_buf() fails because it is
being passed garbage.
Our unit tests link against a number of shared libraries that were also
linked with the problematic linker. It seems to be only one of those
libraries that is causing these problems (the one containing the TmoMap
definition above). This library is linked like so:
g++ \
-pthread \
-m32 \
-Wa,--32 \
-march=i686 \
-fmessage-length=0 \
-ggdb \
-pthread \
-lrt \
-ldl \
-Wl,-rpath=/test/unitTestFramework/lib/linux \
-Wl,-rpath=/test/unitTestFramework/gmock/gmock-1.6.0/lib \
-Wl,-rpath=/test/unitTest/lib \
-L<...>/gcc_linux_sfk-linux_4.6.3/lib \
-lstdc++ \
-L/test/unitTest/lib \
-L/test/unitTest/obj/testmain \
-ltestmain \
-L/test/unitTestFramework/gmock/gmock-1.6.0/lib \
-lgtest \
-lgmock \
-fPIC \
-shared \
-lstdlibStub \
-o /test/unitTest/lib/libosesimstub.so \
/test/unitTest/obj/osesimstub//test/stubs/ose/ose_sim.o \
/test/unitTest/obj/osesimstub//test/stubs/ose/tmosv_sim.o
Any ideas what might be going on here, or how to figure out where things
are going wrong?
Thanks,
Doug
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Odd ld behaviour starting at version 2.22
Thanks. That got me pointed in the right direction.
The problem does appear to be in the linker script, and I'm fairly sure that it
is related to the initialization order of
static constructors and/or destructors.
The 2.22 linker script does this:
.init_array :
{
KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*)
SORT_BY_INIT_PRIORITY(.ctors.*)))
KEEP (*(.init_array))
KEEP (*(EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o )
.ctors))
}
.fini_array :
{
KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*)
SORT_BY_INIT_PRIORITY(.dtors.*)))
KEEP (*(.fini_array))
KEEP (*(EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o )
.dtors))
}
And this breaks our library. If I change that to do what the 2.21.1 linker
script did, while still using the 2.22 linker:
.init_array :
{
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
}
.fini_array :
{
KEEP (*(SORT(.fini_array.*)))
KEEP (*(.fini_array))
}
it works. I can't make the opposite change (use SORT_BY_INIT_PRIORITY with the
2.21.1 linker) because I get a syntax error,
presumably because SORT_BY_INIT_PRIORITY is a new feature.
It's not clear to me yet how the order has changed, or why the order actually
matters for this particular library.
Am I confused about what's actually in the .init_array and .fini_array
sections? There is also .ctors and .dtors
which I thought contains the static ctors and dtors.
Thanks,
Doug
-Original Message-
From: Nicholas Clifton [mailto:ni...@redhat.com]
Sent: November-03-14 7:14 AM
To: Douglas Graham; bug-binutils@gnu.org
Subject: Re: Odd ld behaviour starting at version 2.22
Hi Doug,
> I'm not actually sure that this is a linker bug, but it sure looks
> like one. Version 2.21.1a of ld works fine, but starting at version
> 2.22 and up to 2.24, we are seeing some odd behaviour that is hard to
> pin down.
If you have a look at the ld/NEWS file in the sources you can see what changed
with the introduction of release 2.22. One item stands out:
* --copy-dt-needed-entries is no longer enabled by default. Instead
--no-copy-dt-needed-entries is the default.
Maybe if you try adding -Wl,--copy-dt-needed-entries to your g++ command line
you will get a different behaviour ? (Just a guess, but worth a try).
> All versions of the linker were built and run on a x86_64
> RHEL 6.4 system specifying only --prefix to configure. The symptoms vary,
Are all the symptoms related to startup/shutdown code ? If so then the
problem could be related to the linker script used to combine all the
object files and libraries together. How about linking with the 2.21
linker script but using the 2.24 linker ?
Just a couple of ideas.
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Odd ld behaviour starting at version 2.22
> .init_array is used by newer versions of gcc to serve the same purpose as > .ctors, > but using a different mechanism to run constructor code. Similarly for > .fini_array. > At a guess, your code is making assumptions about the order in which > destructors > are run. If you google for "g++ static destructor order" you'll find lots of > other people with the same problem. Ok thanks. It's not just destructors though, since we have at least one test suite that starts to act weird part way into its execution. I assume this has something to do with the order that ctors are run in. Without having had time to do any more digging, I find it a bit odd that a hashmap at file scope that was never written to could be affected by the order in which ctors are run. As long as it got constructed properly at *some* point, I can't see what else could go wrong. But hopefully it'll be come more clear when I get time to dig deeper. I'll definitely do some googling now that I know what to google for. Thanks, Doug ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
