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

[Fedor Sergeev via Phabricator via llvm-commits]

fedor.sergeev added a comment.

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

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


https://reviews.llvm.org/D33868