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