This is an archive of the discontinued LLVM Phabricator instance.

[Solaris] gcc runtime dropped support for .ctors, switch to .init_array
ClosedPublic

Authored by fedor.sergeev on Jul 12 2017, 4:41 PM.

Details

Summary

crtbegin.o from gcc toolchain as configured on latest Solaris
(with --enable-initfini-array) does not have support for .ctors.

Clang needs to switch to .init_array. Doing it unconditionally
is fine since older Solaris configurations do support .init_array.

Diff Detail

Event Timeline

fedor.sergeev created this revision.Jul 12 2017, 4:41 PM

Note, that LLVM has already been changed to honor use-init-array on Solaris:

https://reviews.llvm.org/rL305948

(before that change setting Options.UseInitArray in clang would not matter).

Added Solaris targets to clang driver test checking for -fuse-init-array.

aaron.ballman edited edge metadata.Jul 13 2017, 6:11 AM

This looks reasonable to me, but I am not overly familiar with this part of the toolchain. You should wait for another LG before committing.

aaron.ballman edited reviewers, added: dlj; removed: cfe-commits.Jul 13 2017, 8:09 AM
aaron.ballman added a subscriber: cfe-commits.
davide accepted this revision.Jul 13 2017, 8:17 AM

LGTM.

lib/Driver/ToolChains/Gnu.cpp
2467

this is really a mess.

This revision is now accepted and ready to land.Jul 13 2017, 8:17 AM
fedor.sergeev added inline comments.Jul 13 2017, 9:12 AM
lib/Driver/ToolChains/Gnu.cpp
2467

Any suggestions on how to improve? :)

dlj accepted this revision.Jul 13 2017, 10:27 AM

I think this change is structurally fine, but I'll defer to others on whether it's actually doing the right thing. (I'm pretty sure it is, but I'm far from an expert on Solaris or Sparc.)

lib/Driver/ToolChains/Gnu.cpp
2467

From my perspective, this is really no worse than what's already here. I tried to avoid changing logic in https://reviews.llvm.org/rL297250, but this function is an example of something that still can use a lot of work.

Since this variable depends on all the parts of the triple, it probably won't break down very cleanly among the various subclasses. That said, if you do want to refactor this, you'll of course want to spend some time to think through exactly how this should work, and spend some time gathering feedback from other Clang devs... so it's probably out of the scope of this patch. I would be happy to help review that change... but, more pragmatically, I'd say land this change first before starting any surgery.

test/Driver/constructors.c
83

Thank you for adding these. :-D Most of the toolchain classes lack explanatory comments about which platform combinations are expected to work for different features, so test cases like this will be invaluable to anyone who wants to refactor parts of the driver.

Can anybody commit this for me, please? :-/

Committed in r308038.