On 02/15/2012 06:09 PM, Rainer Orth wrote:
> Paolo Bonzini <bonz...@gnu.org> writes:
> 
>> This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
>> gcc_AC_INITFINI_ARRAY.
> 
> Here's an updated patch that does so.  During testing, I found one
> additional complication, though.  With the Sun as/GNU ld combination on
> Solaris 11/x86, after the bootstrap had completed, all programs linked
> against libgcc_s.so.1 SEGVed with a stacktrace like this:
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1 (LWP 1)]
> 0x00002000 in ?? ()
> (gdb) where
> #0  0x00002000 in ?? ()
> #1  0xfefcd73f in call_array () from /usr/lib/ld.so.1
> #2  0xfefcd8bd in call_init () from /usr/lib/ld.so.1
> #3  0xfefcc8e1 in setup () from /usr/lib/ld.so.1
> #4  0xfefdcfd8 in _setup () from /usr/lib/ld.so.1
> #5  0xfefc0674 in _rt_boot () from /usr/lib/ld.so.1
> #6  0x0804796c in ?? ()
> #7  0x08047ab0 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> The problem turned out to be that with
> 
>       .section        .init_array
> 
> as generates 
> 
> Section Header[5]:  sh_name: .init_array
>     sh_addr:      0               sh_flags:   0
>     sh_size:      0x4             sh_type:    [ SHT_PROGBITS ]
>     sh_offset:    0x344           sh_entsize: 0
>     sh_link:      0               sh_info:    0
>     sh_addralign: 0x4       
> 
> i.e. empty sh_flags.  gld seems to mishandle this, since the
> corresponding .initarray entry is bad, as can be seen with runtime
> linker debugging:
> 
> $ LD_DEBUG=init LD_PRELOAD=./libgcc_s.so.1 ls
> [...]
> 02032: 1: calling .initarray[0]:0xfed77100: ./libgcc_s.so.1
> 02032: 1: calling .initarray[1]:0x2000: ./libgcc_s.so.1
> Segmentation Fault
> 
> If I change the above to
> 
>       .section        .init_array,"aw",@progbits
> 
> everything works fine with as/gld, but breaks again with gas/gld since
> gas warns about @progbits here.  It turned out that 
> 
>       .section        .init_array,"aw"
> 
> is fine with both assemblers, while as doesn't understand @init_array.
> That's what the patch below uses.
> 
>> Can you test Linux too?  The change of -e0 looks good, but I'd rather check
>> on the actual system.
> 
> This patch has been bootstrapped on i386-pc-solaris2.{8, 9, 10, 11} with
> as/ld, gas/ld and gas/gld, i386-pc-solaris2.11 with as/gld, as well as
> x86_64-unknown-linux-gnu, correctly detecting .init_array etc. support
> on the gld configurations.  It was also included with
> sparc-sun-solaris2.* bootstraps, but even with gas/gld the configure
> test fails.  I've got to investigate that separately.
> 
> Ok for mainline now?
> 
> Thanks.
>       Rainer
> 
> 
> 2012-01-20  Rainer Orth  <r...@cebitec.uni-bielefeld.de>
> 
>       PR target/50166
>       * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Require gcc_SUN_LD_VERSION.
>       Define _start.
>       Remove -e 0 from $gcc_cv_ld invocation.
>       Only use __GLIBC_PREREQ if defined.
>       Enable on Solaris since Solaris 8 patch.
>       (gcc_SUN_LD_VERSION): New macro.
>       * configure.ac (ld_ver) <*-*-solaris2*>: Refer to
>       gcc_SUN_LD_VERSION for version number format.
>       * configure: Regenerate.
>       * varasm.c (get_elf_initfini_array_priority_section): Use
>       get_section instead of get_unnamed_section to emit
>       .init_array/.fini_array with default priority.

Build parts are okay.  I cannot approve the varasm.c changes.

Paolo

Reply via email to