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

Chandler Carruth chandlerc at google.com
Mon Jun 18 11:08:04 PDT 2012


On Mon, Jun 18, 2012 at 10:49 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> > 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.
>
> Recent version have it. I found the bug when using gold 2.21 which
> doesn't. What seems to happen is:
>
> * In an old linux system, the linker leaves ctors in .ctors,
> crtbeginS.o has a call to __do_global_dtors_aux. The net result is
> that _init calls the constructors.
> * In an all new linux system, the compiler uses .init_array (or the
> linker moves it there) and crtbeginS.o has nothing to do with
> constructors.
> * If we have a compiler that doesn't use .init_array and gold 2.21 in
> a new linux system, we hit the bug.
>
> 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.


Thanks to Andrew for explaining some of this to Rafael, and thanks to
Rafael for breaking it down and getting it through my thick skull. =] I now
understand what's going on much better. It is indeed not as bad as I was
expecting.

However, as Rafael says, this is an annoying ABI change to handle. It seems
that the song-and-dance to maintain backwards compatibility has been
achieved, but the cost has been to introduce a pretty nasty dependency on
newer versions of ld / gold in order to cope with '.o' files built by old
compilers (which we are sometimes stuck with).

In figuring out how best to support this situation, the question I'm left
with, and would love if someone from the GCC community familiar with the
initial change could answer is: why was this change worth the cost we're
now paying? What is the expected upside to putting constructors in
.init_array?

Thanks,
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120618/59dc6cb2/attachment.html>


More information about the llvm-commits mailing list