On Mon, Jun 18, 2012 at 11:08 AM, Cary Coutant <ccout...@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.
