PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

Richard Guenther richard.guenther@gmail.com
Fri Jun 3 12:31:00 GMT 2011


On Fri, Jun 3, 2011 at 6:31 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, May 18, 2011 at 8:57 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Apr 26, 2011 at 6:05 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Mar 31, 2011 at 7:57 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Mon, Mar 21, 2011 at 11:40 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Mon, Mar 14, 2011 at 12:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>> On Thu, Jan 27, 2011 at 2:40 AM, Richard Guenther
>>>>>> <richard.guenther@gmail.com> wrote:
>>>>>>> On Thu, Jan 27, 2011 at 12:12 AM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>>>>>>>> On Tue, Dec 14, 2010 at 05:20:48PM -0800, H.J. Lu wrote:
>>>>>>>>> This patch uses .init_array/.fini_array sections instead of
>>>>>>>>> .ctors/.dtors sections if mixing .init_array/.fini_array and
>>>>>>>>> .ctors/.dtors sections with init_priority works.
>>>>>>>>>
>>>>>>>>> It removes .ctors/.ctors sections from executables and DSOes, which will
>>>>>>>>> remove one function call at startup time from each executable and DSO.
>>>>>>>>> It should reduce image size and improve system startup time.
>>>>>>>>>
>>>>>>>>> If a platform with a working .init_array/.fini_array support needs a
>>>>>>>>> different .init_array/.fini_array implementation, it can set
>>>>>>>>> use_initfini_array to no.
>>>>>>>>>
>>>>>>>>> Since .init_array/.fini_array is a target feature. --enable-initfini-array
>>>>>>>>> is default to no unless the native run-time test is passed.
>>>>>>>>>
>>>>>>>>> To pass the native run-time test, a linker with SORT_BY_INIT_PRIORITY
>>>>>>>>> support is required.  The binutils patch is available at
>>>>>>>>>
>>>>>>>>> http://sourceware.org/ml/binutils/2010-12/msg00466.html
>>>>>>>>
>>>>>>>> Linker patch has been checked in.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This patch passed 32bit/64bit regression test on Linux/x86-64.  Any
>>>>>>>>> comments?
>>>>>>>>>
>>>>>>>>
>>>>>>>> This updated patch fixes build on Linux/ia64 and should work on others.
>>>>>>>> Any comments?
>>>>>>>
>>>>>>> Yes.  This is stage1 material.
>>>>>>>
>>>>>>
>>>>>> Here is the updated patch.  OK for trunk?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> H.J.
>>>>>> ----
>>>>>> 2011-03-14  H.J. Lu  <hongjiu.lu@intel.com>
>>>>>>
>>>>>>        PR target/46770
>>>>>>        * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Removed.
>>>>>>
>>>>>>        * config.gcc (use_initfini_array): New variable.
>>>>>>        Use initfini-array.o if supported.
>>>>>>
>>>>>>        * crtstuff.c: Don't generate .ctors nor .dtors sections if
>>>>>>        NO_CTORS_DTORS_SECTIONS is defined.
>>>>>>
>>>>>>        * configure.ac: Remove gcc_AC_INITFINI_ARRAY.  Add
>>>>>>        --enable-initfini-array and check if .init_array can be used with
>>>>>>        .ctors.
>>>>>>
>>>>>>        * configure: Regenerated.
>>>>>>
>>>>>>        * config/initfini-array.c: New.
>>>>>>        * config/initfini-array.h: Likewise.
>>>>>>        * config/t-initfini-array: Likewise.
>>>>>>
>>>>>>        * config/arm/arm.c (arm_asm_init_sections): Call
>>>>>>        elf_initfini_array_init_sections if NO_CTORS_DTORS_SECTIONS
>>>>>>        is defined.
>>>>>>        * config/avr/avr.c (avr_asm_init_sections): Likewise.
>>>>>>        * config/ia64/ia64.c (ia64_asm_init_sections): Likewise.
>>>>>>        * config/mep/mep.c (mep_asm_init_sections): Likewise.
>>>>>>        * config/microblaze/microblaze.c (microblaze_elf_asm_init_sections):
>>>>>>        Likewise.
>>>>>>        * config/rs6000/rs6000.c (rs6000_elf_asm_init_sections): Likewise.
>>>>>>        * config/stormy16/stormy16.c (xstormy16_asm_init_sections):
>>>>>>        Likewise.
>>>>>>        * config/v850/v850.c (v850_asm_init_sections): Likewise.
>>>>>>
>>>>>
>>>>> PING:
>>>>>
>>>>> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00760.html
>>>>>
>>>>
>>>> Any comments?  Any objections?
>>>>
>>>
>>> Here is the patch updated for the current trunk.  OK for trunk?
>>>
>>
>> PING,.
>
> Hi Richard,
>
> You commented my patch was stage 1 material:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01989.html
>
> Is my patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00760.html
>
> OK for trunk?

I can't approve the configury changes and would like to defer
to target maintainers for the target specific changes.  That said,
I'm not familiar enough with the area of the patch.  But yes,
it's stage1 now - so if anyone else wants to approve this patch...

Richard.

> Thanks.
>
>
> --
> H.J.
>



More information about the Gcc-patches mailing list