[PATCH] D33868: [Solaris] emit .init_array instead of .ctors on Solaris (Sparc/x86)

[Davide Italiano via Phabricator via llvm-commits]

davide added a comment.

In https://reviews.llvm.org/D33868#772189, @fedor.sergeev wrote:

> In https://reviews.llvm.org/D33868#772185, @davide wrote:
>
> > Can you add a test?
>
>
> Sure, will do it.
>  Can you tell me where should I add it - test/Target?
>  I was planning to add some clang tests, but that can only happen after more changes to clang (enabling -fuse-init-array by default).


You can probably mimic what we do for Linux here (see how it's tested).

>> Also, I'd like to know the following: does the Solaris linker (whatever it's called) support mixing'n'matching of `.ctors` and `.init_array` ?
>>  (gold implements some logic to merge them in order to ensure all the global constructors are called even if you have some objects file with `.ctors `and some others with `.init_array` as input.
> 
> 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.
>  If you have an object with .ctors you have to link it with ctors-handling g++ runtime ("old" one).
> 
> 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.

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).


https://reviews.llvm.org/D33868