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

Rafael Espíndola rafael.espindola at gmail.com
Mon Jun 18 07:20:09 PDT 2012


ccing the gcc list and Cary Coutant.

The issue comes from gcc pr46770. Cary, have you tried implementing
the --reverse-init-array option? Does it solve the problems you were
seeing?

Can libstdc++ be fixed to work with the iostream static constructors
being in .ctor or .init_array? Would you be interested in such a fix?

>From llvm's point of view the main concern is if this ABI change
should be considered a hiccup to be worked around in systems like
fedora 17 or it is something more permanent.

If I understand it correctly, gcc's configure checks if the target
support .init_array and uses it unconditionally if it does, is that
correct?

On 17 June 2012 23:15, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 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




More information about the llvm-commits mailing list