[llvm-commits] [patch][rfc] How to handle static constructors on linux

[Rafael Espíndola]

I recently upgraded to fedora 17 and now found out that libstdc++ 4.7
requires c++ constructors to be handled with .init_array instead of
.ctors.  I have not produced a self contained testcase, but when
building the google protocol buffer compiler (part of chromium) if the
static constructor for

....
 namespace std __attribute__ ((__visibility__ ("default")))
{
...
  static ios_base::Init __ioinit;
....
}
.....

ends up .ctors, the compiler crashes during startup. Patching the
clang produced assembly to use .init_array fixes the problem.

This is unfortunate, as the semantics of both are not exactly the
same, since the runtime process them in reverse order.  My first
intention was to ask for approval for the attached patch, but I was
told by Chandler that this ABI change caused enough problems for them
that they reverted it internally. It looks like there are now two ABIs
and  we will have to support both.

On the clang side, we can reuse the logic for detecting the gcc
installation to know which ABI to use, but it is not clear what the
best way to forward that to llvm is. Traditionally this is handled in
the triple, the eabi suffix for example, but fedora 16 and 17 share
the same triple (x86_64-redhat-linux) and have different ABIs. This is
also a problem for llc: It doesn't know anything about which gcc
installation is being used, if any, and the IL represents static
constructors at a higher level and it is codegen's job to select a
section.

The best I could think of so far is

* Add a command line option to codegen for using .init_array (defaults
to false).
* Have clang produce that option when it detects a gcc 4.7 based distro.

This would mean that without any options llc would produce the wrong
result on fedora 17 (and other gcc 4.7 distros?), but hopefully cases
that depend on cross TU construction order are not common enough for
this to be a big problem for users. Clang would still produce the
correct results.

Diego, do you know if it is the intention that the new ABI will be
maintained? If so, do you think all users will be able to upgrade to
it or will we (gcc and clang) have to keep both for the foreseeable
future?

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 2541 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120617/55f2167e/attachment.obj>