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>