Honor Options.UseInitArray on Solaris targets.
Addressing PR33293.
Differential D33868
[Solaris] emit .init_array instead of .ctors on Solaris (Sparc/x86) fedor.sergeev on Jun 3 2017, 11:45 AM. Authored by
Details Honor Options.UseInitArray on Solaris targets. Addressing PR33293.
Diff Detail Event TimelineComment Actions Can you add a test? Comment Actions Sure, will do it.
Solaris ld does not do any merging of .ctors and .init_array: ] old-g++ -c ctor1.cc ] elfdump -c ctor1.o | egrep "ctors|init_array" Section Header[6]: sh_name: .ctors Section Header[7]: sh_name: .rel.ctors ] clang++ -c ctor2.cc ] elfdump -c ctor2.o | egrep "ctors|init_array" Section Header[6]: sh_name: .init_array Section Header[7]: sh_name: .rel.init_array .ctors are being handled purely by crtbegin.o ] old-g++ ctor1.o ctor2.o ] elfdump -c a.out | egrep "ctors|init_array" Section Header[21]: sh_name: .init_array Section Header[23]: sh_name: .ctors ] ./a.out I() <--- from init_array C() <--- from ctors main ] new-g++ ctor1.o ctor2.o ] elfdump -c a.out | egrep "ctors|init_array" Section Header[21]: sh_name: .init_array Section Header[23]: sh_name: .ctors ] ./a.out I() main But that is an overall problem of a Solaris system that results in g++ incompatibility between versions. Changing behavior of clang/llvm does not make anything worse here, since it is ctors that misbehaves and this change allows to get rid of ctors. Comment Actions You can probably mimic what we do for Linux here (see how it's tested).
This is an unfortunate effect of transitioning. I agree there's nothing can be done in the compiler as it can't possibly know about other object files, but you might consider fixing this in your linker, assuming you have a compelling use case (tracking down these bugs is fairly annoying). Comment Actions X86 constructor.ll test updated, SPARC constructor.ll added. ] bin/llvm-lit test/CodeGen/SPARC/constructor.ll -- Testing: 1 tests, 1 threads -- PASS: LLVM :: CodeGen/SPARC/constructor.ll (1 of 1) Testing Time: 0.22s Expected Passes : 1 ] bin/llvm-lit test/CodeGen/X86/constructor.ll -- Testing: 1 tests, 1 threads -- PASS: LLVM :: CodeGen/X86/constructor.ll (1 of 1) Testing Time: 0.23s Expected Passes : 1 Comment Actions So what am I supposed to do here? Comment Actions I pinged Rafael and asked him to take another look. |