This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch][rfc] How to handle static constructors on linux


[Re-sending this to try to got through to the GCC mailing list...
Sorry for the duplication to others... My reply is at the bottom]

On Mon, Jun 18, 2012 at 11:08 AM, Chandler Carruth <chandlerc@google.com> wrote:
> On Mon, Jun 18, 2012 at 10:49 AM, Rafael EspÃndola
> <rafael.espindola@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]