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

Chandler Carruth chandlerc at google.com
Mon Jun 18 11:17:05 PDT 2012


On Mon, Jun 18, 2012 at 11:08 AM, Cary Coutant <ccoutant at google.com> wrote:
>> So this is not as bad as I was expecting (old programs still work),
>> but it is still a somewhat annoying ABI change to handle. I think we
>> can add support for this in clang in 3 ways:
>>
>> 1) Require new linkers when using gcc 4.7 libraries.
>> 2) Ship our own versions of crtbeginS.o (and similars).
>> 3) Use .init_array when using gcc 4.7 libraries.
>>
>> I have most of option 3 implemented. Chandler,  do you still think
>> that this is a big enough ABI breakage that it should not be
>> supported?
>
> You keep using the terms "ABI change" and "ABI breakage", but I think
> you're using those terms a little too freely. The ABI does not specify
> the order of initializers across compilation units, so the difference
> in behavior -- while perhaps unfriendly -- does not even qualify as an
> ABI change, and certainly not as an ABI "breakage".

Not at all. The ordering is not the problem from an ABI stance. My
concern was with a mixture of object code or dynamic libraries
compiled in both the old and the new world. Rafael had indicated that
this mixture produced a crashing program.

However, he has clarified all of the various layers of compatibility
present, and I agree the problem is much less bad than it originally
seemed. It seems all that remains is a rather firm version dependency
-- a recent linker with support for migrating '.ctors' ->
'.init_array' is required to support old object files.

> Furthermore, if you're working in chromium, you should be aware that
> the new behavior is exactly what the Chrome developers are arguing
> for, as it makes the startup faster. It sounds to me like you're
> working at cross purposes with the other developers on that project.

Ah, perhaps this goes to answer my question from the other mail: why
switch to '.init_array'?


I agree that reversing the order is essentially orthogonal, and has a
straight forward fix, which is largely a convenience to avoid changing
behavior needlessly.




More information about the llvm-commits mailing list