On Mon, Jun 18, 2012 at 7:20 AM, Rafael Espíndola
<rafael.espind...@gmail.com> wrote:
> 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?
The GNU linker has support to merge .ctor's into init_array. Does the
gold linker have the same feature? This seems more like the real fix
rather than just hacking around the issue.
Thanks,
Andrew Pinski
>
> 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
