> 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". 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. If the change in behavior is breaking the protocol compiler, I think the best solution would be to fix it so that it doesn't depend on behavior that is explicitly undefined by the ABI. Otherwise, it's going to be fragile and non-portable. Having said all that, I'm still very much in favor of reversing the .init_array, as I believe that makes much more sense than the current behavior. It does, however, change existing behavior for (non-ctor uses of) .init_array, so there will be changes in behavior either way. The only way to preserve the exact status ante is to disable GCC from placing ctors in .init_array and to use the linker's --no-ctors-in-init-array option. Sorry, I have not yet implemented the --reverse-init-array option in gold. -cary