Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Feb 2012 17:51:21 +0100
From:      John Marino <draco@marino.st>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        Pedro Giffuni <pfg@freebsd.org>, freebsd-toolchain@freebsd.org
Subject:   Re: DragonFly added support for ELF preinit, init, and fini arrays
Message-ID:  <4F3D3409.3040006@marino.st>
In-Reply-To: <20120216154730.GL3283@deviant.kiev.zoral.com.ua>
References:  <4F3C5A3A.6050107@FreeBSD.org> <20120216154730.GL3283@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2/16/2012 16:47, Konstantin Belousov wrote:
> On Wed, Feb 15, 2012 at 08:22:02PM -0500, Pedro Giffuni wrote:
>> Hello;
>>
>> FYI, this commit in DragonFly seems interesting:
>>
>> http://leaf.dragonflybsd.org/mailarchive/commits/2012-02/msg00146.html
>>
>> It appears like linux had them from a while and some years ago they started
>> using them for C++ in gcc:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01872.html
>>
>> cheers,
> If you read the commit message, you will notice something at the end.
>
> I have WIP patches to add support for the init arrays to our rtld.
> It is not tested yet, and I want to ponder more about the ABI changes
> in csu that I introduce.
>
> In fact, I am more interested in having answer to the question, what
> immediate and long-term use do we have for the feature. Also, I want
> non-artificial test cases for DT_INIT_ARRAY and DT_FINI_ARRAY.
>
> http://people.freebsd.org/~kib/misc/init_array.1.patch

Hi Konstantin,
One obvious case for the immediate use is the building of gold linker in 
binutils 2.22.  By default, it moves constructors into the init array, 
so gold will segfault if it was linked with itself.  (The workaround is 
to patch option.h file to change the ctors-in-init-array to false before 
building gold so it has the same behavior as gnu ld).

Also, GCC now supports generation of .init_array and .fini_array 
directly rather than using .ctor and .dtor sections.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

I can't say how much current software depends on the functionality 
working though.  Mostly this would be transparently handled by gcc and 
the linker.

The main benefit from what I can tell is that .init_array is more 
efficient at startup because the array is executed in order while .ctors 
is executed in reverse.  .ctors is also considered legacy and supporting 
it is "backwards compatible".  Apparently ARM eabi only uses .init_array 
and not .ctors.  There seems to be a slow movement to eliminate .ctors 
on the linux side with rationale that .init_array support has been 
available 11 years and the gcc patch is an indication of that attitude.

John






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3D3409.3040006>