This is an archive of the discontinued LLVM Phabricator instance.

[Solaris] emit .init_array instead of .ctors on Solaris (Sparc/x86)
ClosedPublic

Authored by fedor.sergeev on Jun 3 2017, 11:45 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

fedor.sergeev created this revision.Jun 3 2017, 11:45 AM
davide requested changes to this revision.Jun 3 2017, 1:49 PM

Can you add a test?
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.

This revision now requires changes to proceed.Jun 3 2017, 1:49 PM

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.

davide added a comment.Jun 3 2017, 2:27 PM

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

fedor.sergeev edited edge metadata.

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

Gentle ping...
... tests are ready.

krytarowski resigned from this revision.Jun 6 2017, 10:06 AM

I will leave it to Davide.

davide accepted this revision.Jun 17 2017, 4:13 PM
davide added a subscriber: rafael.

I think this is fine, but please wait if @rafael has comments about it.

This revision is now accepted and ready to land.Jun 17 2017, 4:13 PM

So what am I supposed to do here?
Is there any chance for @rafael to actually comment on this?
Is it a blocking action or am I allowed to find somebody to integrate this for me after some lead time?

So what am I supposed to do here?
Is there any chance for @rafael to actually comment on this?
Is it a blocking action or am I allowed to find somebody to integrate this for me after some lead time?

I pinged Rafael and asked him to take another look.
In general if somebody doesn't reply after one week it's OK to ping the patch.
Please be patient as people from time to time have a non-trivial review backlog.

This revision was automatically updated to reflect the committed changes.